st_goliath

I find the irony here quite amusing: While we usually marvel at the cyberpunk dystopia laid out on paper/screen in front of our eyes, the characters in the story typically never stop to question any of it. They take the world they live in completely for granted, making it clear to us, the reader/viewer, that they don't know any different, adding to the extend of the dystopia on display.

And here we are discussing a toilet that probably films you piss, analyzes the data and uses it as input for a video game, all using a built-in computer and display mounted on top. A touch screen no less, because the team involved in developing this, despite probably countless meetings, never even gave a second though towards hygiene, I guess.

A marvel of technology that I could imagine the likes of Neal Stephenson describing in loving detail over at least two pages, describing how the data is hauled off to some remote machine in a data center, collecting statistics of no use to anyone, from hundreds of such installations, all secured only by a couple default passwords.

And our reaction to this is: So? What off it?

I guess this should be the revert he mentioned, for those interested:

https://github.com/curl/curl/commit/c2df780a97d9913eb20a55d4...

Tungsten and gold have a comparable density. This company sells realistic looking, fake gold bars, that are supposed to pass typical tests as well. They are advertising them for e.g. as a prop for trade fares and such. Whoever would need a prop at a trade fare to pass a chemical test is anyone's guess...

Yes, fake gold bars like this have obviously already been used for fraud, e.g. of the top of my head: in 2016 a then-18-year-old in Göttingen sold 259 fake bars to a local bank for a total of ~300k Euro until somebody realized it. [1](German)

[1] https://www.haz.de/der-norden/wieso-hat-niemand-das-falschgo...

An other quite interesting concept (also a little less "out there" and actually, successfully tested) is the NERVA engine, also linked at the bottom of the article[1].

It uses a nuclear reactor to heat up a single propellant (liquid hydrogen) which then rapidly expands as it goes out the nozzle at the end, resulting in quite high specific impulse and is more efficient than a chemical rocket.

If we want to go really far out in terms of crazy rocket designs, there is also the concept of the nuclear salt-water rocket[2][3].

This one uses enriched plutonium or uranium salts, dissolved in water, inside a neutron-absorbent fuel tank design. The water is pushed out through a pipe, where an uncontrolled chain reaction starts. If it goes fast enough, it explodes right inside the engine bell, pushing the rocket. The proposed design in the original paper is supposed to generate hundreds of gigawatts of thermal power. This is comparable to the Chernobyl reactor #4 when it exploded, but unlike Chernobyl (which only exploded once) or the pulsed Orion engine, it could run continuously. The stuff that flies out of the nozzle easily reaches escape velocity of the solar system.

[1] https://en.wikipedia.org/wiki/NERVA?useskin=vector

[2] https://en.wikipedia.org/wiki/Nuclear_salt-water_rocket?uses...

[3] Obligatory Scott Manley video: https://www.youtube.com/watch?v=cvZjhWE-3zM

Triangles in 3D euclidean space have the advantage of being uniquely defined by 3 vertices that have the nice property of always sitting on a single plane. There's no linear transformation you could apply that results in something other than a well-defined, planar triangle. The worst that might happen is collapsing it into a line or a point.

The same cannot be said for quads. If you e.g. have 4 vertices where 3 are sitting on the same plane, but the 4th isn't, there are 2 different, possible ways to subdivide this into triangles. In addition to all the possible non-linear surfaces one might image occupying that space.

Old OpenGL and Direct3D versions did have quad and arbitrary polygon rendering support. IIRC from vague memory, the above scenario was something you were supposed to avoid and results varied between graphics card vendors.

On a side note: If we are talking purely 2D, some old 2D software rendering systems used trapezoids as basic primitives, defined by their top and bottom edges. For instance, the X11 XRender API explicitly supports drawing trapezoids. They are easy to rasterize, interpolate across and quite flexible. Many other 2D shapes can be conveniently composed from them, including screen space triangles, if you were to implement a software rasterizer.

If not, here are part 1 and 2 of opening up and repairing the thing:

- https://www.youtube.com/watch?v=dmHaCQ8Ul6E

- https://www.youtube.com/watch?v=CP5dfjxdkQ4

And a 47 second time-lapse video of the Globus doing 7 orbits:

- https://www.youtube.com/watch?v=nDHtJy9cpC0

(there is an earlier time lapse video as well, linked in the blog post)

I suppose it causes an integer underflow and tryies to in-place destruct in an empty buffer?

The std::vector class is somewhat inconsistent about safety and maps a lot of it's operations directly to unsafe, raw array access. The C++ STL contains a lot of historical baggage and design inconsistencies.

For instance, while std::vector has an `at(index)` method, that does proper bounds checking and throws an exception if the index is out of range, it also has an overloaded `operator []` that mimics array syntax that will happily write out of bounds, trashing the heap.

Statute or nautical football fields?

No, it's a Chinese lesson.

A "thing" or "stuff" in Chinese is 东西 (dōngxi). That's literally "east-west" if you pick the individual characters apart. That's what the footnote refers to.

Calling somebody 不是个东西 (bùshì ge dōngxī) means something along the lines of being good for nothing, i.e. an insult. Translating it literally, it would be calling somebody "not a thing".

> It was easy and cheap, before microcontrollers were as friendly to use as they are now.

I got started with AVR microcontrollers with a DIY parallel port ISP adapter: just cut a printer cable in half, solder in 4 resistors and you were good to go :-)

Then spend a ridiculous amount of time re-learning assembly to port the parallel port LED blinking program from DOS to the AVR.

Only needing the few scavenged parts and buying just the MCU was a lot cheaper than buying the "recommended" adapter cable or some eval board, making the whole thing affordable for my 13 year old self.

> ... I wouldn't think anybody runs production code on ...

famous last words. There ought to be something like rule 34 for software: "If it can conceivably be used in that way, somebody's doing just that in production, somewhere safety critical."

> ... neither inventing their own algorithms nor implementing existing algorithms ...

Even if you just cobble together existing primitives from battle tested libraries, if you don't fully grasp their properties or interactions, you can still shoot yourself in the foot pretty heftily.

Particularly, encrypting data at rest is an entirely different beast on it's own.

Personally, I don't really like blindly praying that old "don't roll your own crypto" mantra for this exact reason. It means so much more than "don't implement crypto primitives from scratch" which people seem to often interpret it as, but is IMO really poorly/vaguely phrased to convey that.

The Netbpm format is amazing if you quickly want to try something out and need to generate an image of some sorts. The P6 binary format is even simpler, you write the header followed by a raw pixel data blob, e.g.:

    fprintf(stdout, "P6\n%d %d\n255\n", WIDTH, HEIGHT);
    fwrite(image, 1, WIDTH * HEIGHT * 3, stdout);

Yes, I know, this obviously misses error handling, etc... The snippet is from a simple Mandelbrot renderer I cobbled together for a school exam exercise many moons ago: https://gist.github.com/AgentD/86445daed5fb21def3699b8122ea2...

The simplicity of the format nicely limits the image output to the last 2 lines here.

Yes, bash does that. It's a bash feature:

https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash....

> Bash handles several filenames specially when they are used in redirections, as described in the following table. If the operating system on which Bash is running provides these special files, bash will use them; otherwise it will emulate them internally with the behavior described below.

> ...

> Bash attempts to open the corresponding [...] socket.

Well, you have to scale everything down by a factor of 10 to map German scales to Austrian ones ;)

We have like 2 or so (?) public broadcasting stations. One of which makes a heroic sacrifice for the audience that wants to see Silversterstadl, so we need to compromise a bit.

Typical Austrian tradition is to get unreasonably shitfaced with friends/relatives throughout the day (same as every other holiday), until you have a sufficiently positive outlook on the new year.

In that state you're then able to bare the presidents new year speech for the purpose of sarcastically mocking it, actually find Mundl's antics afterwards funny and can round it off with "Dinner for One", right before going outside and playing with explosives. If you survive, you get to listen to the final parts of The Blue Danube afterwards.

Also here in Austria, usually broadcast shortly before midnight.

Not sure if the author confused it with Australia, which is confusingly mentioned under "Popularity across Europe", or lumps us up with Germany, which misses the fun factoid that we split up again in 1945 (and also tends to get people over here surprisingly pissy).

> You have to implement it once on kernel side and once in userspace

I actually did think about this before posting my original response, and I think this is unrealistic from a practical perspective. To elaborate a bit on that:

First of, a one-size-fits-all structured format is a lot more complex than a directory with ASCII files in it that each store an integer and IMO invites itself to feature creep (i.e. more complexity).

Complexity is IMO the root cause of the issue originally discussed here (if not most bugs). The more code, the more complexity, the more bugs. In my experience, software will always have bugs, complex software more so.

There can never be a "one-true-implementation" for userspace. Because of the complexity, people will write their own ad-hoc versions. They "only need that one thing" and don't want to drag the whole library dependency in. Some people think they know better and write their own "lightweight/suckless/..." versions because the kernel one is "bloated", or "that API sucks". Some will rewrite it in their favorite programming language for whatever reason. NIH syndrome, bike shedding, ...

Then, what if a widely used implementation has a bug? Especially if it's the "one-true-library" itself? You now need to roll out a fix. Across countless Distros, embedded devices that might get maintenance updates every couple years at best, set-top boxes, network appliances, ... You'll have programs floating around that are statically linked against a specific version of the one-true-library. In the end, we have a variety of differently bugged parsers in use, simply because of the spread in versions alone. The original problem that we wanted to solve, remains.

Of course there are issues with the more simplistic approach, but in the case of e.g. sysfs, those are typically corner cases. Adding a one-size-fits-all special, structured format for everything introduces a whole lot of unneeded complexity everywhere else as well. A "one-true-format to solve all problems" that needs special library code for processing IMO introduces a whole lot more problems than it solves.

While procfs has a lot of historical baggage, sysfs is rather specific about the layout and providing only a single value per file, as plain ASCII, rather than using anything complex that has to be parsed. Structure is implemented via the filesystem.

In return, the kernel side API for sysfs is also a lot cleaner and allows to more-or-less expose individual variables as tuning knobs for a driver.

Of course there are edge cases, and there are e.g. some binary interfaces as well (e.g. for providing direct register access, or implementing a firmware upload interface for a device).

ABI compat issues aside, I think that implementing "a standardized [structured] record format" as suggested in the comments here is a rather bad idea, going into exactly the wrong direction by adding complexity rather than reducing it, which would definitely cause even more parsing related issues in the long run.

> It's terribly non-obvious how to deal with correctly.

Like the post says: read the whole thing into memory and do a reverse search for the last ')', i.e. strrchr

Once you are aware of the problem, it's obvious how to solve it, but I do agree that the hidden danger here is not immediately obvious at first.

Austria, HTL from age 14 to 19 (https://en.wikipedia.org/wiki/H%C3%B6here_Technische_Lehrans...). Wikipedia calls it college for some reason, our English teacher always called it a high school (with a focus on engineering disciplines; EE in my case) and compared it to such when showing us charts of education systems in UK, US vs Austria.

I'm not sure how various schools/countries do ICT education in comparison, but I at least heard that friends of mine who stayed in grammar school past age 14 were exposed to Borland Delphi at some point.

Every time the topic "tiny webserver in C" come up on HN, I always thought that the people who never did something like this were perhaps self-taught (similar to "write a tiny shell in C" which was also a standard exercise in our universities operating systems course). I have a hard time trying to imagine how one could possibly teach a college or university level course on networking without doing exercises like that.

Come to think of it, another surprisingly simple protocol you might want to have a shot at for the fun is VNC.

It's also really rewarding to end up with a picture on the screen, once it works. Nowadays the entry barrier to real-time graphics programming is IMO really darn high for beginners, but a simplistic VNC server might get you a step closer to the MS-DOS days, where we could literally draw pixels into RAM.

(Or, you could just extend your tiny HTTP server to support Motion JPEG, which is basically just a single HTTP response header, followed by a diarrhea of JPEG images.)

"Write a tiny web server in C" was a standard exercise when I was in high school, and later again in university. I think I did that at least 3 times as an assignment so far.

I reused the final version for a different university exercise instead of bothering with Tomcat as I was required, and back in 2015, dumped the end result here: https://github.com/AgentD/websrv where I kept adding to it for a while for fun.

The HTTP 1.x protocol itself is pretty dead simple (if you ignore chunked requests/responses and such) and the more interesting part was actually the socket code.

Back in school, our teacher had us write a simple forking server and consult the corresponding man pages (man 2 socket, man 7 socket, man 7 tcp). It was an acceptable minimal solution to not even look at the client request, respond with a static string containing a dummy response header and HTML page, which absolutely works. Bonus points for parsing the request path and sending a file back, more extra points if the path was a directory and your server sends back an "index.html" file, further points if it instead generates an HTML directory listing on the fly.

When I visited our former teacher a couple years ago, he had modified the exercise somewhat. He brought a Beagle Bone Black with him to class, with a bunch of I2C sensors attached to it, and the extended exercises now revolve around reporting temperature/humidity/... to the browser.

So, for "resource" I recommend the HTTP example on Wikipedia, as well as "Beej's guide to network programming" (as have others), as well as the man pages for quick reference.

> ... there are a bunch of internal APIs: linked lists come to mind.

Those already have unit tests:

https://github.com/torvalds/linux/blob/master/lib/list-test....

using an existing in-kernel test framework no less.

If you step up into the 'lib' directory (containing generic in-kernel utility code) you might notice that there are a whole bunch of C files already that have an "_test" suffix in their name (or "_kunit").

Maybe not "typical" unit tests, but Linux does have test cases for stuff like the generic library code (data compression, encryption, ECC, ...) in the shape of special modules that, when built, run through their test cases during boot up.

It gets harder to test low-level driver code, but some subsystems have similar sets of tests, e.g. MTD has a set of tests for drivers & flash chips that they interact with. In 2016 I ported those tests to userspace as part of mtd-utils. The tests for the kernel crypto stuff I mentioned would also test hardware accelerators, if enabled.

Filesystems have the fstests project (formerly xfstests, as it was originally written when porting XFS to Linux), testing filesystem semantics and known bugs. There is something similar for the block layer (blktests). The downside being that those test suits take rather long to do a full run.

Those are just things that I can think of on top of my head, given the subsystems that I have interacted with in the past. Static analysis on the kernel code is also being done[1][2], there are also CI test farms[3][4], fuzzing farms[5], etc. As others have pointed out, there is a unit testing framework in the kernel[6], IIRC replacing an older framework and ad-hoc test code.

[1] https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.h...

[2] https://scan.coverity.com/projects/linux

[3] https://cki-project.org/

[4] https://bottest.wiki.kernel.org/

[5] https://syzkaller.appspot.com/upstream

[6] https://kernel.org/doc/html/latest/dev-tools/kunit

A German speaker would pronounce the letter 'i' as an English speaker would pronounce 'e'.

Many German words contain an "elongated i" which is written as 'ie', but still sounds like 'e' in English, just a little drawn out and more pronounced.

In contrast, English has words like 'weird' which has an 'ei' construct in it but a pronunciation somewhat similar to what 'i' would sound like in German. Funny enough, in German 'ei' would be read like an English speaker would pronounce the letter 'i'.

So with the pronunciations more or less swapped, I guess, for an English speaker who heard the pronunciation of words like "Wiener", the spelling of the 'i' before the 'e' might feel counterintuitive, and they might, intentionally or not, "correct" it while typing.

This is from the same guy who wrote the absolutely wonderful NAND gate article[1] that also featured on HN about a year ago (and was taken surprisingly serious) [2].

[1] https://sebastiancarlos.medium.com/the-nand-gate-one-gate-to...

[2] https://news.ycombinator.com/item?id=28756727

Most of the ALIX boards use something called TinyBIOS[1][2]. Browsing through the source tree from the pcengines site, it doesn't seem to share any relation with this project here.

The current APU boards use Coreboot[3]

[1] https://www.pcengines.ch/alix.htm

[2] https://www.pcengines.ch/tinybios.htm

[3] https://www.pcengines.ch/apu2.htm

As a native German speaker, I don't understand your problem. It's very much not opaque, plain terminology that easily conveys meaning. ;-)

Perhaps, we should compromise and name it after Leonhard Euler? That should clear up the confusion.

> Could it be mitigated by safer, modern tech?

Like... Coverity Scan?

In my experience, this bug looks like a classic example for something that Coverity should find.

And it looks like sudo is already on there: https://scan.coverity.com/projects/sudo

The last analysis was 2 weeks ago. I wonder if this CVE is among the outstanding memory corruption and illegal access defects (5 each).

> the seventh byte past the buffer is then zeroed/set to the null terminator. I wonder if and how this is exploitable.

Well, looking at the upstream code, the original value is saved away before zeroing it out and then unconditionally restored after running crypt.

If sudo is single threaded and crypt() doesn't malloc() anything, I don't think that can be exploited. Worst case would be a segfault if the password was somehow close enough to a page boundary.