speleo_engr

Totally agree. I've been making the same argument elsewhere on this thread. People are disagreeing with saying things were simpler back then. I don't know how anyone can have fond memories of a 16-bit CPU with segments or bank switching compared to a modern flat model and think it was simpler.

That sounds like a great idea, but you today we can't even synthesize arbitrary VHDL/Verilog code efficiently. The author needs an understanding of hardware architecture to write something that synthesizes versus just a test harness not intended to be synthesized.

Sure you can learn a lot but I have no idea why you would choose Turbo C in 2020 over say a Raspberry Pi with GCC. Turbo C (discontinued in 1990) is going to expose a bunch of irrelevant things today, as even most microcontrollers are 32-bit:

painful 16-bit near/far memory model

a single task operating system (DOS) that has been long obsolete

no support for networking or threads

I could go on and on.

I don't think its going to get any design starts, nor is that the intent. There are companies with rock solid legacy applications that want to continue to run them on newer hardware. VMS first ran on the VAX (long dead), then Alpha (dead), and finally Itanium (recently dead). x86 will let these legacy apps run for a few more decades.

Those are all shaping (and bidi) issues though, independent from encoding. UCS-4 is a single Unicode code point and the simplest encoding. Shaping may combine code points many to one, one to many, have ordering issues, etc. I think it is important for people to understand how shaping works and the code point/glyph distinction. Trying to duplicate the effort of the shaper when processing strings UCS-4 is going to lead to a world of hurt. Even English text with strings like "1/4" and ligatures in the font may display as a single glyph (that's font specific shaping, not encoding).

I've heard more than one person tell me they don't need to worry about text shaping since they are using UTF-8. (That statement doesn't make any sense) There is a lot of confusion with Unicode text rendering stack.

Undoubtedly there are really hard jobs. I'd put a mover on that list as well, along with oil field worker.

But it seems dismissive to say a dev can't claim burnout because they aren't doing something physical. When a junior dev, I once went into the office 23 days in a row and was usually there until 11 pm or midnight, sometimes later, sometimes earlier. I got burned out and left. It wasn't good for my health or relationships. I bet if you worked hours like that loading a truck you at least would have gotten overtime.

Yes, it is ultimately TT. The order goes: UTC -> TAI -> TT

I could argue the TAI to TT is the second step. But let's put the pedantry aside: Is your best answer of something made easier in the modern world by leap seconds ensuring that solar noon happens at exactly 12:00:00 four times a year on an exact line of longitude for the time zone? And 4 times a year would require a time zone that does not honor daylight time, otherwise it is twice.

I'm not some crackpot here talking about the absurdity of leap seconds. US, China, Australia, Japan, S. Korea are on board for discussions about abolishing to happen in 2023.

> So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds.

That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are unnecessary complexity with the frequency at which they happen.

I've spent a lot of time finding objects in the sky to high accuracy with astronomical algorithms. The first step is always converting from UTC to TAI. See Astronomical Algorithms by Jean Meeus if you don't believe me.

Your noon example works for a single longitude in a time zone and the time between subsequent noons on two different days will only be exactly 24 hours 4 times a year. It seems unnecessarily complex to push annual leap second updates to preserve something like as obscure as these 4 events for the 24 time zones exactly on the line of longitude to the accuracy of a second.

See the Wikipedia on abolishing leap seconds, "that the drift of about one minute every 60–90 years could be compared to the 16-minute annual variation between true solar time and mean solar time, the one hour offset by use of daylight time, and the several-hours offset in certain geographically extra-large time zones"

https://en.wikipedia.org/wiki/Leap_second

Your article is about time zones, not leap seconds?

The US has put forth a proposal to abolish leap seconds. It is now supported by China, Australia, Japan, and South Korea. The ITU keeps punting on actually voting on it - it's now scheduled for 2023.

https://en.wikipedia.org/wiki/Leap_second

A day already drifts... every single day in fact. Why is 0.9 sec the magic threshold for maximum drift? Why can't it be 1 minute of drift, or 1 hour of drift? We are putting out problematic corrections for something a minor drift on the scale of years that should be happening on the scale of centuries or millennia in my opinion.

How are leap seconds useful if you are an astronomer? I am genuinely curious what problem in the year 2019 is easier due to leap seconds.

I have worked on code that needed to do astronomical calculations to do things like:

position of sun, moon, Mars, Earth, and spacecraft

ECI <-> ECEF

All of these depend on a conversion from UTC to TAI. It's covered in books like Astronomical Algorithms in the intro: https://www.willbell.com/math/MC1.HTM

I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle programmatically. People think time increases monotonically and it's confusing to push it any other way.

The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. The fact that a clock sometimes reads 23:59:60 is also absurd, as is the "possibility" of a 23:59:59 being a forbidden time on a certain date if we ever add a leap second of the opposite sign.

Depends on the company size and how long they have been around. Based on experience, I will always ask the following at a smaller company:

Have you ever been close to missing payroll?

Depending on the answer, make sure to find out when was the last time they missed.

It is very stressful to work at a place that has cash flow issues. They may very well be honest that they are on the cusp of big deals and/or funding. But wouldn't you want to know if there are short term issues before you start?

It's been a while since I used VxWorks, but I hated Workbench as well (prefer using a plain old makefile). One of my favorite features of VxWorks was the shell you could get on a serial port. It was quite powerful, even letting you do REPL with C functions which was pretty awesome for debugging.

Another "favorite" feature of VxWorks was how they disabled floating point by default in tasks (at least on the LEON and PPC). Always led to confusion and frustration by someone new to the platform.

If you come at it from an engineering approach (e.g., electrical engineer), it doesn't look like that at all. In fact, the focus is on filters and spectral analysis. It looked something like this when I was at Georgia Tech:

First, you learn about the convolution operation that, given any input function x(t), get the output of any linear time-invariant circuit as y(t). The convolution integral is nasty, professors make you feel the pain a bit. Then introduce the Laplace transform to make the computation much easier. Then go to continuous time, continuous frequency Fourier transform. Talk about frequency domain a bunch, learn filter topologies, etc. Circuits class over.

Now comes a signal processing class where you learn about discrete-time signals. First, talk lots about sampling. Then, get introduced discrete time convolution. Now, learn the z-transform and the discrete time Fourier transform (DTFT) for a discrete-time, continuous frequency signal. Mostly discuss filtering and spectral analysis. Intro to signal processing class over.

Learn about sampling the DTFT in the frequency domain. This is the DFT, which is usually presented as a sum that would require O(n^2) operations to compute. Learn that this corresponds to circular convolution and learn about zero padding for traditional convolution. Finally, get presented with Cooley-Tukey FFT algorithm for base-2. Focus is still signal and spectral analysis. Talk lots about windowing. You may get a mention that convolution corresponds to polynomial multiplication here. Or maybe they talk about grade-school multiplication, its really the same thing as polynomial multiplication with a carry. Senior level signal processing class over.

Yep. Communal pots & pans will be very abused and not cleaned after something was burned or scorched in them.

How is vinyl more durable as far as physical media goes than a CD (digital format)? Vinyl can easily warp when improperly stored, degrades every time it is played, and even a small scratch result in audible imperfections. A CD at least can be scratched heavily and still be identical to the original thanks to forward error correction by Reed-Solomon codes.

I've used XZ to compress tarballs of backup. XZ was useful so I could store more backups on an external hard drive. I have seen bit rot on some of these files (stored on a magnetic HDD), in the sense that the md5sum of the .tar.xz archive no longer matches when it was created. What do you suggest for creating parity/ECC in this case? I'm aware of parchive, but is that the right choice and in what configuration?

I kind of doubt this story. What kind of radiation would you have from Chernobyl?

My understanding is that bit flips (SEEs) are typically caused by energetic particles like cosmic rays. To simulate upset damage on Earth, you typically need to decap the IC and go to a testing facility that directly hits the wafer with particles. It seems unlikely that somewhere near Chernobyl that there would be particles energetic enough that didn't get stopped by the IC packaging.

Gamma radiation gives total ionizing dose effects that degrade chips until the point they no longer work. Those shoot right through the chip packaging. But I don't think it typically causes upsets.

If Android is on a camera, I want some sort of a hypervisor situation where it does not interfere with real-time operations. My Canon T4i will very responsively snap a picture once I have locked the focus, aperture, and shutter speed. I do not want to lose that and "gain" lagdroid.

Nuclear deterrence has been a controversial topic for 50 years. There have always been arguments for nuclear disarmament instead.

I took the point of this article to be that the ICBM portion of the US triad does not work on NK since a missile must overfly China or Russia.

I personally don't think there is much risk of war with NK. NK has everything to lose and nothing to gain by starting any sort of war.

Triple buffering confusingly means different things. Both you and the OP are correct. The OP meant something in line with what Wikipedia says: https://en.wikipedia.org/wiki/Multiple_buffering#Triple_buff...

"In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the image has been sent to the monitor, the front buffer is flipped with (or copied from) the back buffer holding the most recent complete image. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag.[1]

Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This can mean that several drawings that are never displayed are written to the back buffers. Nvidia has implemented this method under the name "Fast sync"."

BSPs weren't new to the Quake engine (Doom had them). Gouraud shading, lighting, and TCP/IP multiplayer are what made Quake revolutionary for the PC. These things existed on SGIs costing $100k for years before too. The optimizations to make this on a PC is why Carmack is genius.

Monospaced fonts simply mean that the horizontal width is constant. While this also means there aren't any kerning pairs, it is a different concept. Simply disabling kerning does not mean a font is monospaced.

Kerning is a table of pairs that allows them to have more aggressive advance values. For example, with a sequential 'V' and 'A', the 'A' could be moved closer to the 'V'. But kerning doesn't have anything to do with the fact that in a variable width font that 'I' is narrower than 'X'.

Posts like this are what keep me coming back to HN.

What do they push instead? Python? Go? JS?

I used to work on flight software for a private company. It seemed like inertia from "heritage" always drove lots of decisions. From my memory, I remember quality assurance from NASA getting hung up on the following items during design reviews:

1) an RTOS they weren't familiar with

2) a language they weren't familiar with (the familiar set was Ada, C, C++)

3) dynamic memory allocation

How much push back did you get from quality assurance?

Having used several different EDA tools, I completely believe this. I don't know how they can be so poor across the board. It is part of the reason I switched from doing software & hardware to just hardware. Life is too short to deal with bugs in synthesis tools.

> That's true of all large institutions; how is NASA different? Is it worse that other large institutions? Nobody can hire and motivate brilliant, excited people on that scale.

I agree, it is difficult. But I'd say it is different than at big companies because there it seems more likely for them to eventually cut loose chronic under-performers.

Another issue they run is if there is a budget cut, NASA won't buy as many spacecraft, but they also don't let people go. So some missions will have way more personnel than needed. This can easily lead to a cost/schedule overruns by the contractors, because now the contractor is getting swarmed by requests from the extra NASA people. I've been in meetings where it is a 10:1 ratio of NASA versus contractor. A meeting that should take an hour takes a day because so many people want to get a word in.

I worked with NASA for a few years. It made me a cynic about a lot of things. You have some people there who are brilliant and very excited about space. You also have people there who are completely incompetent but will be able to retire in their position in 30 years as long as they don't commit a HR violation.

NIH is a serious problem in all of the NASA centers.