skysight-inc/HackerNews huggingface dataset:
I was just looking this up earlier for a different conversation, and the 125GBP original 1982 price of the Spectrum would have been 430 quid in today's prices. (You can get a cheap laptop for half that price today.) It brings home why Sinclair thought it so important to keep the costs as low as possible -- it might have been three times cheaper than the competition, but that was more because the competition was a seriously expensive piece of kit rather than because the Spectrum was truly "dirt cheap".
Searching on it goes to 1995 written post. I have not read this, just sharing:
https://paws.kettering.edu/~jhuggins/humor/design.html
I agree, on ChromeOS it's entirely possible for their to be generic images that support a wide ranges of devices all sharing the same update path (like Windows, MacOS).

on Android? very much still in the embedded space on how it's built. Linux on ARM is generally still a shit show.

I'd rather ChromeOS get a Android runtime (not a VM) and replace Android, than the other way around.
Volkswagen confirms its low-cost ID.2 EV is still on track to launch
> My observation is that the [o1-like] models are better at evaluating than they are generating

This is very good (a very good thing that you see that the out-loud reasoning is working well as judgement),

but we at this stage face an architectural problem. The "model, exemplary" entities will iteratively judge and both * approximate the world model towards progressive truthfulness and completeness, and * refine their judgement abilities and general intellectual proficiency in the process. That (in a way) requires that the main body of knowledge (including "functioning", proficiency over the better processes) is updated. The current architectures I know are static... Instead, we want them to learn: to understand (not memorize) e.g. that Copernicus is better than Ptolemy and to use the gained intellectual keys in subsequent relevant processes.

The main body of knowledge - notions, judgements and abilities - should be affected in a permanent way, to make it grow (like natural minds can).
Practice of Neurosurgery on Saturn
We already use carrotsearch internally so you could replace the java util classes like HashMap and HashList with it to reduce memory usage a bit. But it won't help much. E.g. all data structures (in any standard library btw) do usually double their size at some point when their size increases and then copy from the old internal array to the new internal array, which means that you need roughly 3x the current size and if that happens roughly at the end of the import process you have a problem. For that reason we developed DataAccess (inmemory or MMAP possible) which is basically a large List but 1. increases only segment by segment and 2. allows more than 2 billion items (signed int).

Another trick for planet size data structure could be to use a List instead of the Map and the OSM ID as index. Because the memory overhead of a Map compared to a List is huge (and you could use DataAccess) and the OSM IDs for planet are nearly adjacent or at least have not that many gaps (as those gaps are refilled I think).

All these tricks (there are more!) are rather tricky&low level but necessary for memory efficiency. A simpler way for your use case could be to just use a database for that, like MapDB or sqlite. But this might be (a lot) slower compared to in-memory stuff.
The French are onto the right track. If Europe is to recover economically and to win some market share in tech, I fully expect it to come from the French.
GameNetworkingSockets from Valve. Maybe not middleware enough? You have to implement the serialization and a state update strategy yourself.

Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. P2P networking / NAT traversal. Encryption.

https://github.com/ValveSoftware/GameNetworkingSockets
Hmm, all those "don't use print" headlines shown in the article seem to be simply click-bait headlines for articles that aren't really shaming print debugging but instead illustrating other debugging tools that some programmers may not know about.

I remember the good old days when I was first learning programming with Applesoft BASIC where print debugging was all there was, and then again in my early days of 8051 programming when I didn't yet have the sophisticated 8051 ICE equipment to do more in depth debugging. Now with the ARM Cortex chips I most often program and their nice SWD interface, print debugging isn't usually necessary. But I still use it occasionally over a serial line because it is simple and why not?
>printing also will likely impact timing and can change concurrent behaviour as well.

I've had a bug like that and the intuitive way to handle it turned out to be entirely sufficient.

The bug (deep in networking stack, linux kernel on embedded device) was timing sensitive enough that printk() introduced unsuitable shifts.
Instead I appended single-character traces into pre-allocated ring buffer memory. The overhead was down to one memory read and two memory writes, plus associated TLB misses if any; not even a function call. Very little infra was needed, and the naive, intuitive implementation sufficed.

An unrelated process would read the ring buffer (exposed as /proc/ file) at opportune time and hand over to the developer.

tl;dr know which steps introduce significant processing, timing delays, or synchronization events and push them out of critical path
Well put, and that's a good part of the reason they're going the way of the Catholic Church.

That said, I'd call it an 'aristocracy' instead. But, tomato/tomahto, ya know?
I kinda want to push back against the blanket statement that there are articles pushing back on print debugging. That implies there’s well known mind share thinking about it?

Is it real mind share? Is it bullshit?

Print debugging is the literal pocket knife of debugging.
I've used both and most of the time I'm still print debugging, because the big advantage of print debugging is that it shows you exactly the kind of information you're looking for and nothing else.
> my soup in a paper takeout container.

There is an increasing use of paper takeout containers. Awful.
I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over.

It's often faster and easier to set things up to run test cases fast and drop some prints around. Then if there's too much unimportant stuff or something else you want to check on, just switch around the prints and run it again.
As a scientist, it’s not always political, but it does take time to progress due to the zero sum nature of funding.

We are in an era of dogmatism when it comes to which questions will be funded to explore, but the pendulum will eventually swing back.

These trends are generational in nature due to older folks having the power of the purse.

Politics is simply preference.
Sure, and North Korea wants to man its border for the eventuality of war with the South. At least that's what everyone would have said before it happened. NK troops in Ukraine weren't on anyone's bingo card.
Never has a copyright infringer been brought up on theft charges.

It is not theft, no matter how much you claim that it is. If I duplicate and distrbute a work you hold copyright in, I have not "stolen" anything from you. I have infringed your copyright.

This is the problem with using "intellectual property" as the terminology. It incentivizes rightsholders to hold the mindset of "ownership", as one does with property. Copyright is a limited term right, after which the rightful ownership of the public enters the picture.
If a good debugger is available, it is a great tool to have. But it is just one out of many tools. Some are more effective than others in different situations.

For example, I rarely used a debugger in my career as an Android driver developer (mostly C), for several reasons.

1. My first step when debugging is looking at the code to build working hypotheses of what sort of issues could be causing the incorrect behavior that is observed.

2. I find assertions to be a great debugging tool. Simply add extra assertions in various places to have my expectations checked automatically by the computer. They can typically unwind the stack to see the whole call trace, which is very useful.

3. Often, there only choice was command-line GDB, which iI found much slower than GUI debuggers.

4. Print statements can be placed inside if statements, so that you only print out data when particular conditions occur. Debuggers didn't have as much fine control.

5. Debugging multi threaded code. Prints were somewhat less likely to interfere with race conditions. I sometimes embedded sleep() calls to trigger different orderings to occur.
Valuable for whom?

No rational being left then.
Or plastic, or whatever else. Leftovers are not an issue, unless I order from a place and they happen to use paper (or cardboard) containers as I cannot store them for too long.
The Daily Cartoonist
If the people don't push back, they deserve it.

Most have no idea what it's like to fly private.
Genesis wants a bigger slice of the US luxury market with new EVs en route
Article is from 1980 and mentions the USSR in the present tense. Surveiller et Punir is from the late 1970s; that’s not exactly a long time for its influence to percolate into the pages of History Today in 1980. This is pretty much what I’d expect from an anglophone article about Siberian exile from the late years of the Cold War.
I agree that 3 is great, but you can also do that in any database, just create your input tables as string only and then perform the necessary operations to move them into typed tables.
I find that which tools I need changes immensely depending on what kinds of projects I'm working on.

When debugging parsers for my toy programming languages print debugging is less helpful and I make heavy use of all the debug tools you mention. The same goes for most types of business logic—writing a test and stepping through it in the debugger is usually the way to go.

But when troubleshooting odd behavior in a complex web app, the inverse is true—there are usually many possible points where the failure could occur, and many layers of function calls and API calls to check, which means that sticking a debug statement prematurely slows down your troubleshooting a lot. It's better to sprinkle logs everywhere, trigger the unexpected behavior, and then skim the logs to see where things stop making sense.

In general I think there are two conditions that make the difference between the debugger or print being better:

* Do you already know which unit is failing?

* Is there concurrency involved?

If you don't yet know the failing unit and/or the failing part of the code is concurrent, the debugger will not help you as much as logs will. You could use logs to narrow down the surface area until you know where the failure is and you've eliminated concurrency, but you shouldn't jump straight to the debugger.
The more expensive Steam Deck uses this kind of glass (nano texture is apparently a fancy way of saying etched glass), so that could be the point of comparison.
I agree with the title that you shouldn't look down on print debugging. You should look down on people who are slow at fixing bugs and who refuse to try tooling to be able to keep pace -- and using print statements can sometimes be a marker of this. But print debugging is just a tool and has its place, and the use of print debugging is not itself an indicator of poor developer performance. If you can find/fix bugs as quickly as I can with a debugger using print statements, then I don't care what you use. If you can do it faster, then I'm going to try to steal your techniques so I can be faster too. If you do it slower, then I hope you would steal my techniques.

Don't care about the tool care about the performance.

Anecdotally, debuggers are faster than print statements in most cases for me. I've been able to find bugs significantly faster using a debugger than with using print statements. I still do use print statements on occasion when I'm developing something where a debugger is very complicated to set up, or in cases where I'm dealing with things happening in parallel/async, where a debugger is less suited. I'm not going to shame you for using print statements, but I do hope that you've tried both and are familiar/comfortable with both approaches and can recognise their strengths/weaknesses -- something I'm not convinced of by this author, which only outlines the strengths of one approach.

Also not a fan of the manufactured outrage of saying people are being "shamed" for using print statements. Coupled with listing a bunch of hyperbolic articles -- many of which don't even seem to be about debugging but about logging libraries.

(Also as a side note: don't forget if you are using print statements for debugging to check if your language buffers the print output!! You'll likely want to have it be unbuffered if you're using print for debugging)
CDE killed off openlook, another nice desktop environment mostly on Sun workstations. Lots of time spent on both, with my optical mouse and optical mouse pad.

Looks like there's an open source clone though

https://sourceforge.net/projects/openlook/
Imo the microecon metaphor is off base. This is about any parallel process being limited by it's serial phases. There are ways of looking at economies that see this process angle where Amdhal's law plays a role. But it's not the rediscovery of microeconomics.
In opposition to US SaaS mostly selling to other US SaaS?
Heh - this!

ZX-Spectrum with 16K RAM cost £100. With 48K RAM it cost £130. The keyboard was bad. Basic commands were assigned to combinations of keys, not typed letter by letter. The cpu was Z80A at almost 4MHz!

Most popular, as it was very compact. Could be smuggled across customs hidden under the coat.
Usually from West Germany. :-) My then country (YU) had banned importing a computer more expensive than 50 DEM (25 Eur). Knew of many kids that had ZX-Spectrum.

Commodore-64 had 64K RAM (not all addresable at once), much better keyboard. It cost £200. Basic programs could be typed normally. Learned Basic and 6502 assembler on it. The cpu was 6510 at almost 1MHz, had few memory mapped io ports too.

My parents relented after 2 years of pestering and bought me one from an authorized dealer. They were not rebelious enough to risk smuggling of ZX-Spectrum clandestine op. :-) The excise and duty paid were astronomical. It cost them £470 or sth like that. Eternally grateful to my parents for that. It changed my life. Knew couple of kids with C64 in addition to 2 of my closest friends.

BBC Micro B was £400. It was exclusive, like royalty, I knew of only one kid that had it.

Trip down the memory lane. :-)
They shouldn’t have to pay for something I buy in a store on their app. Apple doesn’t get to own the entire economy just because they make an operating system
Most likely "The Brothers Karamazov".
You'd hate my (functional!) watch cufflinks then.
They’re after you, are they? Those people who you’ve never met, never once interacted with? Who have never made any attack on US soil? Who instead are facing attacks from US weapon systems onto their soil? Those guys, are “after” you?

Absolutely wild mentality.
Shouldn't they be paid a decent wage for the teaching, itself?
Wounded Tigris By Leon McCarron

This book is not something you can read and forget. Leon and his small team travel down the entire Tigris River. They start in Turkey, go through all of Iraq, and end in the marshes.

I picked it up, thinking it would be an interesting adventure with a heavy dose of history. Instead, I got an utterly fascinating account of the river, its ecosystem, the heavy impact of pollution and water management, and the cultural impact of all these changes on the people who live alongside it.

Longer thoughts here: https://shepherd.com/bboy/2024/f/bwb

So far Ive asked around 1,200 readers for their 3 fav reads of the year. Here are the nonfiction results so far: https://shepherd.com/bboy/2024/nonfiction

You can share yours too if you want :)
I wonder -- if they were to restart from scratch today, would they do the same thing? If not, which stack would they choose?
> Shapes capable of tiling a 2D space need a minimum of two corners, but in 3D the rules are different

...for 3d they have bent the definition of "corner" so that a section of the 3d shape showing a corner is not considered a corner in the 3d space. It remains interesting, but.
It's not free. The search doesn't work unless you sponsor someone on GitHub.

Even then, it may not work as it could be a scam.
https://news.ycombinator.com/item?id=16289380
Not long ago this happened: https://apnews.com/article/hajj-heat-deaths-mecca-saudi-arab...

> More than 1,300 people died during this year's Hajj pilgrimage in Saudi Arabia as the faithful faced extreme high temperatures at Islamic holy sites in the desert kingdom
As long as the on-call coverage is as specified at the time of hiring, this is just a difference in form of payment.

If I receive 100 total units of compensation, I'd way rather get 100 units of base pay (and 0 on-call pay) than 90 units of base pay and 10 units of specific on-call pay. (What if the company eliminates on-call? What if I get injured and my insurance only covers base pay? Severance is usually based only on base pay; I would not be paid on-call while I'm on PTO or other paid leave, annual raise percentages typically apply to base pay, etc...)
Meanwhile on X people are freely uploading their health data because Elon asked them to.
Agree, there are some time travel debuggers though but either only for some programming languages or expensive commercial or only for linux e.g. rr-debugger[0]. Also there is rerun [1] that is only for image processing pipeline debugging.

I wish there was something similar like rerun but for code: you record the whole program running and capture all snapshots then stop it running. Now you can analyze all app execution and variables even offline and use any data queries, modify prints without execution and feed it too AI as extra context. I guess RAM would be a big obstacle to make it work since you would either have to capture snapshot at every program modification or some less snapshot but some diffs between what changed.

[0] https://rr-project.org/

[1] https://www.rerun.io/
All that tells me is that you have never used a good debugger. There is no "setup" and stepping through lines is trivial.
There are loads of articles discouraging print debugging, and it's a very real thing that people fight against (and for). Print style debugging is the first thing most programmers learn, and for some it absolutely becomes a bad habit.

And to be clear, print debugging and pervasive, configurable logging are very different things and the latter is hugely encouraged (even with logging levels), while the former is almost always suboptimal. Being able to have your client turn on "DEBUG" logging and send you the logs after some abnormal behaviour is supremely useful. Doing "prinftf("Here!")" in one's project is not, or at least not remotely as useful as better approaches.
Pretty much the same thing.
Thinking of Into Thin Air still makes me feel cold, intense book :)
For me the algorithms work better. I get way too much rubbish on Twitter even though I don't follow or want to know these people or that information.
I mean, (a) see Betteridge's Law of Headlines, but (b) I think this illustrates a common confusion about Twitter. Twitter was many things to many people. If you used it mainly to consume the ramblings of self-important bloviators, then, yeah, substack might be a substitute, but that’s not what everyone used it for.
too much use of italic / oblique
> lol. This is definitely not my experience.

Which part doesn't vibe with you? Are the seniors not stuck in their way of doing things? Or they are stuck in their way of doing things, but never admit defeat?

> So the exotic tech is introduced to solve a symptom to the underlying issue without the crucial step of reconsidering the box the system sits in.

What does this even mean?

> Being old or having worked at the same company for 10 years doesn't automatically mean someone is truly skilled and could actually mean their experience is extremely limited.

Right. And it's really hard to have a discussion with them, because they'll bring the discussion back to seniority, or popularity, or boringness of the technology, or say that the scale issue probably won't happen, or the race condition probably won't happen.
I’m not sure what you mean. The shapes in the article do not have corners by the definition I would use… they do have edges and it left me wondering if you could tile 3d space with edge-free shapes.
Even without a race condition, concurrency itself can make debuggers difficult to use. Debugging async code almost feels pointless.
> print debugging is problematic since the developer has to be diligent about removing it once it is not longer needed.

Linters make this a non-issue, and most modern development environments support them.

https://eslint.org/docs/latest/rules/no-console

https://docs.astral.sh/ruff/rules/print/

In situations where for whatever reason it's infeasible to use a linter, a basic grep can surface prints in a codebase reliably enough.
But why you hire consultants to solve core security problems?

Furthermore, surely it would just be one guy who knows OS and FPGA stuff and another guy to check it?

What I'm arguing for is that a sensible solution to security problems is to avoid complexity, so that things can be obviously secure.

Carefully defined interfaces designed to be clear, impossible to misinterpret and which are designed to be parsed and implemented without doing anything requiring some kind of fiddly parsing that can lead difficulties, and small enough that someone can implement them in an afternoon; and then you combine that with a machine inherently robust to things like buffer overflows such as Harvard architecture type things, and it's easy even for a single engineer to program something like that up on an FPGA.
I remember from a video of Cody's Lab that metallic gold is safe, but oxidized gold is toxic. https://en.wikipedia.org/wiki/Gold#Toxicity But it's very difficult to oxidize gold, and even gold the salts try to go back to the metallic form, so most of the times it's not a problem.
>I appended (...) traces into (...) memory. (...) An unrelated process would read (...) at opportune time and hand over to the developer.

I did something similar to debug concurrent treatments in Java, that allows to accumulate log statements in thread-local or instance-local collections and then publish them with possibly just a lazySet():

https://github.com/jeffhain/jolikit/blob/master/src/main/jav...
In my case, I started with the ZX-81 and never emigrated, but I can relate to everything else. Thanks to Sir Clive, I have a great career and lots of fun with hobbies that are mostly related to computers. 10/10 would do it again!
Do you think this is scalable?
As far as I can tell, what they provide is essentially old school phone booths, just without requiring a coin. That is as anonymous as it used to be, just now it's free. It doesn't really work for scams or etc in any modern sense because it doesn't scale. You can only have one call going at a time.
My only complaint about print debugging is the sheer volume of commented out console.log statements I see across code bases. Or worse, not commented out and happily logging away on prod. Seriously, leave your console open as you browse around — you’ll be astounded by the amount of debug output just rolling along on production.

Delete your debug cruft!