jforberg

Maybe the store was recently opened? This project is from last year, I just finished the write-up now.

NUC is a single board computer :)

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.

I probably would have if it had been available at the time. This project was actually done last spring/summer.

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.

> challenges

rm -rf /var/tracking_data/jforberg

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.

> Our observations are consistent with Einstein’s general theory of relativity.

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.

But your example looks nothing like Json.

That looks completely inscrutable to me. Like a sequence of magic words. I don't see the connection with JSON at all.

If you'd like to hear the case against OOP in modern programming, the Rich Hickey talks are a pretty good place to start:

* The value of values

* Simple made easy

* Are we there yet?

I'm on mobile, but you'll find these easily on the google.

> "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.

Gotta get rid of all those nasty pure functions. Can't have any of that cruft in muh object oriented language.

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.

Spotify did it right; they managed to put together a service that is actually better than piracy in the ways that matter to a typical consumer.

The movie and TV industry have instead put great effort into building services that are significantly worse than piracy.

And nobody can understand why movie piracy is still rampant, while music piracy is receding.

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.

What if we could have examples on our homepage that actually made the product seem useful in some way...

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.

Indeed. What I would really like is a way to toggle it on case-by-case basis. With -fwrapv you have to convince the code owner to toggle it globally, which can complicate things unless you are the owner.

That sounds reasonable. I agree that overflow is often a bug (and in GCC can use -ftrapv to enforce that view). But overflow is also frequently what you want in algorithms that deal with counters or differences of sums. Maybe point out that there are well-defined operators available in Zig as well?

I'm not immediately seeing how non-wrapping arithmetic can enable significant optimisation. What could be faster than an integer add? If you have an example, I would be very interested (the classic "infinite loop" example is not particularly meaningful in my view).

I always assumed that C left this undefined mostly to support non-two's complement machines, which should probably not be a concern anymore. That's the only explanation I can come up with that explains why unsigned arithmetic is well-defined, but not signed arithmetic.

Nice! That's something I often wish GCC had.

The section about overflow put me off. Undefined semantics is one of my least favourite parts of C. It seems from the article that Zig is leaving not only signed overflow but also unsigned overflow as undefined (or runtime crash in "safe" mode, which is equally as bad). In C at least unsigned arithmetic is well-defined so I could get away with some casting back and forth.

This irks me especially badly since the underlying hardware operations are almost always well-defined, but in my "high-level" language I constantly have to worry that I missed something and maybe the compiler will "optimise" my + into something other than addition.

Is there a fully well-defined addition operator in Zig? What about a well-defined shift operator? This might make me, as a professional C programmer, more interested in a new C-like language.

In a system with virtual memory, you would typically ensure that address 0 (i.e. the lowest page) is unmapped. This causes an error condition if the address is ever read or written, which is useful because 0 is used as a placeholder value (i.e. NULL) in many situations. But this is a conscious decision by the system not to use this page, there's nothing technically stopping you from mapping it and putting some data at virtual address 0.

In a bare-metal environment, there's nothing saying that physical address zero must be unused by the hardware designer.

So I think it's quite the opposite: There's no requirement that address 0 must be unoccupied in any situation, it just so happens that many operating systems choose to leave it unmapped as a debugging aid for developers.

As a Swede, I wish I could say that Assange could come here and face justice without fear of being extradited to the US. But I'm not sure if that's true.

> Plays and movies aren't just people spewing lines non-stop.

Screenplays contain more than just lines.

That might be a valid argument for making -ftrapv the standard. It's certainly not an argument for keeping it undefined. Most -f options tweak the standard in some way and defining overflow would not make -ftrapv suddenly go away.

You have several options, at least if you are willing to stick with GCC/Clang. Passing -fwrapv will give you well-defined (wrapping) signed overflow, which is often the native machine behaviour anyway. If you are interested in catching overflow when it happens, you can use intrinsics like __builtin_add_overflow. These look at the overflow flags present on many machines to let you know if the operation overflowed so you can handle it any way you like. If you are of the opinion that overflow should never happen in your program, you can pass -ftrapv which asks the compiler to crash your program if overflow ever occurs.

> with no possibility to jump directly to it

How about '/examples'? Maybe you should take some time to actually learn how 'man' works before you start bashing it online...