If you think the price is high, I would point out that the SSD I used cost €200 new when I purchased it back in mid 2022. A used 120 GB SSD by contrast can be had for maybe €10 which alone would explain the difference in cost.
Now if 120 GB is enough for your application, that's a good value so more power to you.
If this was going to be used for some "big and serious" application, maybe different choices would have been made. Hopefully it was clear from the post that my goals here were the exact opposite!
In my own anecdotal experience of running a hobby server on Arch for several years, I haven't experienced anything to make me think the distro is unsuitable for server work.
Yes, I considered that and agree that it would have been nicer! I didn't pursue it for this project because my jury-rigged SD boot was working fine and I wanted to move on to other parts of the system.
It rarely makes sense. Pointer to const is a contact between caller and callee. A signature like char <star>strdup(const char <star>) says "I take a pointer to memory that I promise not to modify, and you get a pointer to memory that you may modify".
Const pointer is a statement about the internal variables of a function definition, usually not of any interest outside the function itself and therefore rarely used.
I mostly deal with openembedded at work and I have few positive things to say about it. I'm sure Nix is much faster and nicer. Frankly it's hard to imagine that the opposite could be true.
> "Virtually all Server OSs get hacked/have had security bugs. Nobody should use them to host or store anything."
Your comparison is flawed. Most server installations are not broken into during their lifetime. But it only takes one copy of a movie getting onto thepiratebay to make it accessible to everyone who wants it. So if DRM cannot prevent every attempt at circumvention, it's useless and can only serve to hinder legitimate use of the product.
> If we accept your premise that DRM == disrespecting customers, then you'll have to account for why people are still selling stuff with DRM, and continuing to make millions and millions of dollars.
No, I don't. The fact that some people accept the deal doesn't prove that there's nothing wrong with it. In this case, the seller unilaterally went back on the deal without the customers being involved at all.
I'm not a DRM fanatic and I do use DRM services on a daily basis. But if a vendor pulls a trick like in the OP, they can't then turn around and ask why some potential customers are pirating the product instead. Their addition of DRM has made the service less convenient than piracy. Remember, it's only your legitimate paying customers who have to deal with your DRM. The pirated version has no DRM.
> The success of DRM'd products refutes your claim, entirely.
The purpose of DRM is to prevent piracy. This has mostly been a failure.
Are you implying that DRM is a solution to piracy? If anything, DRM is a big driver for piracy, and its success rate is near zero. Virtually all major DRM-"protected" works are available on thepiratebay shortly after release. Sometimes before release.
The "better solution" is to treat your customers with respect and let them own their bought goods. Gog.com is a good example here, in my opinion.
What definitely doesn't work is to burden your paying customers with digital locks and hurdles to enjoyment, that the pirates will shortly find a way to remove for the non-paying audience.
This is true, but if anything it reinforces my point that continuing past a signal is the exception, not the rule.
In the general case services are not at liberty to just exit(), they need to perform some kind of active cleanup action before exit. So the signal handler would set an "exit flag" somewhere and the EINTR would be an indication for the main loop to check this flag before continuing.
The only common case I can think to continue past signals is SIGHUP, which some services interpret as a command to re-read their configuration file. In this case, you are essentially doing a shutdown and startup sequence anyway, only in a possibly more efficient way. E.g. the case of a web server, if you were previously listening on port N there's no reason to believe that the new config file won't ask you to instead listen on port M. So you will be closing down most connections anyway, and catching SIGHUP is mostly an optimisation as exiting and restarting would have a similar effect.
This discussion seems to ignore the fact that being blocked in a "long-running system call" is the normal state for many (most?) Unix services.
If you look at `ps ax` on your system, you'll likely see about a hundred processes. But if you look at `top`, you'll see only a handful of processes having non-zero CPU usage. Why? Because most processes are just waiting (in a system call) for something to do. A web server is blocked in a select/poll/epoll() call waiting for a connection. Your shell is blocked in a read() call waiting for you to type something. This is just the normal way that a main loop is implemented on Unix.
When you kill one of these processes, they need a way to break out of their loop and with the EINTR approach, they get a chance to break and exit.
I'm far from convinced that a "majority" of services want to just catch signals and carry on.
No, your point is still extremely muddled. Cuda and Wolfram are both compilers/runtimes, they fill exactly the same role of translating high-level code into something that can run on hardware.
Guess what, all you need to prove in order to get a new "valid" cert is that you control the server. And, if you control the server then you already have access to the original certificates, so you probably don't even need new certs.