skysight-inc/HackerNews huggingface dataset:
Short Linux history – linux adventure on ~30 years old gnu/linux distro
Hey everyone!

I just took the plunge and recorded my first-ever YouTube video about the brief history of Linux. I've been in the Linux administration, DevOps, and related professions for the past 15 years and am super passionate about sharing what I've learned.

One of the unique aspects I'm bringing to this channel is using Slackware 15 as the main Linux distro for teaching. I believe diving deep into Slackware gives a solid foundational understanding of Linux. For those of you who've worked with it, you'll know just how much it can teach you, and for newcomers, you're in for a real, authentic Linux experience!

My main goal with this channel is to share my knowledge and contribute to this amazing community that has given so much to me over the years. As it's my very first video, I'm eager to get your invaluable feedback on content quality, presentation style, and any other constructive criticism you might have.

https://www.youtube.com/watch?v=3qmOA03yV2U

A little more about me: My journey began as a curious teenager trying to make sense of the terminal and has brought me through a myriad of experiences to where I am today.

By sharing and learning together, we can strengthen this community even further. If you have a moment, I'd be truly grateful if you could check out the video and let me know your thoughts. Any interactions like likes, shares, comments, and of course, subscribing would be a big morale boost and motivate me to churn out more valuable content for everyone.

Thanks so much for your time and support. I'm looking forward to all our future interactions and discussions!
That's not even close to the same quality of nagging, on a single distro.
Oh yeah... I love the Linux version of Accounting CS. It's great. You know what else is great? The Linux version of CCH ProSystem fx is also rock solid.

Ohhh wait. Those things don't exist. Just like a bunch of EHR software that I have to support doesn't exist either.

They all run on Windows. Most of this stuff doesn't even run on Mac OS X.

The business world runs on Windows. Period. That'll change when Linux developers start making software of the same caliber and ease-of-use as Windows. Until then, nothing changes. And this childish - and I'm being very generous with that assessment - idea that everyone has a "choice" is ridiculous.
OsmAnd~ in F-Droid is the free build of OsmAnd+ from Google Play, IIRC.
With this kind or ranking, there is a ton of noise so the top few likely correctly reflect the methodology but the ordering of the lower ones is meaningless.
The real questions surround typical startup issues:

- Dilution. You will get very heavily diluted.

- Shenanigans. There are all kinds of horror stories about the endless methods used to basically screw over the "little people" in startups. A major one is the already extremely rare "successful" exit where you will likely be subject to an extended lockup period (often at least one year) where the stock price will tank and leave you with a fraction of what you had on paper at the time the deal closed. The "big people" get paid first and take huge chunks out of the cash portion of any acquisition at the real value when the deal closes.

As others have noted the ROI on startups for all but the top and preferred equity holders is pretty terrible.

Take cash now.
Hey Eric,
Considering onboarding is so critical to the success of a product, I’m glad you created a space to help out in this area. Love it
I haven't listened to Car Talk in years, but I can still remember the number listeners would call. I'm going to go back and listen to some reruns. I imagine it's aged gracefully.
I’ve used both debuggers and print/log statements. More recently, I’ve learned the value of even seeing if I’m in the right part of the code by inserting 1 / 0 (or any way to raise an exception if 1 / 0 doesn’t blow things up). If I can’t even get a bad arithmetic error, I don’t need to worry about the rest of it!
I know people "don't do" warm rooms. Though honestly, 74 doesn't even qualify as that.

They should get used to it. Cooling large spaces is a huge waste of electricity, and it's not like 74 degrees is anywhere near hot or miserable.
I’ve been happy testing private behaviour with tests
directly alongside the code.

I'm intrigued but I don't understand. What does this look like? What language is this?
Looks like it is way more likely to get a job if you know fortran or cobol than delphi.
I believe this was / is still believed to be the "best historical keyboard" to be used with Emacs: https://en.wikipedia.org/wiki/Space-cadet_keyboard#/media/Fi... it has Ctrl on both sides.

Even if the 76's Emacs wasn't designed for it, most people with decades of Emacs experience would start salivating just from looking at this keyboard. I believe, that when anyone using Emacs is designing key bindings, be it today, ten or twenty years ago -- they think about something like Space Cadet.
Sounds like you want OCaml (or StandardML but OCaml is more "active")

Since, as I feel it, Rust was/is started as an attempt to bring roughly the ML (Hindley-Milner) type system to the area of `systems` (non-garbage collected) development.

In the early days of Rust I thought of it as type inference & algebraic data types meets C++ (now kiss!). But then the borrow checker stuff went in there and it took a different turn.

And I think you'd be surprised by how large the OCaml package community is.

People who work in Rust would likely find OCaml very familiar after a week or two of hacking.

The other option is Swift, but it's pretty ghetto-ized into the Apple ecosystem.
There’s a parallel in beasts of burden. Do some smallholders use them? Yes. Are they economical? No. Mechanization undercut the value proposition of slave labor and beasts of burden due to the costs of upkeep and their nature of needing rest and recuperation. With slaves you also had to have a an infrastructure to keep them from escaping -also true for animals but keeping animals corralled is cheap.
That's why I wrote a "pinch" in the OC. m4 is arguably better than cat as a barebones template engine. The moment you start doing anything beyond simple includes and variable extrapolations, it is time to switch something more modern and robust.

I guess autoconf/sendmail still use m4 because there wasn't anything better at the time that doesn't come with a kitchensink attached.
These tests are being extracted from an editor project I work on. The tests themselves use the OSSignpost API for high-precision measurements combined with the XCText infrastructure for driving the UI and capturing the measurements. I've been using this combination for performance testing for a while now. It can be flakey a bit, but that's kind of the nature of UI testing sometimes. Still really great when it works.

The only truly interesting test is one that creates a 1 million line document, measures the loading time (extremely fast) and then measures the time it takes to navigate to the final line in the document. This exercises the layout system. It's really fast. On my machine TextKit 1 can do it in about 70 ms, and TextKit 2 in around 10. This isn't quite good enough for 120 fps UI on macOS machines that support it, but it's really close.

Live scrolling and window resize are both things I'm really interested in testing. But, the UI automation framework doesn't, as far as I know, have good ways of driving those interactions. But I may be able to cook something up. Ideas welcome!
Great point and sometimes checklists are indeed not enough. My previous post was triggered more by the "I think I did step 13," part of the post I was responding to. That is not a flaw with checklists but a flaw in the safety culture of the operator team. It should never happen that you lose track of where you are in the process because human memory is unreliable, rather you should fix that through better processes and outsource the memorizing to paper.
Is there any other languages that let you use async on embedded/bare metal? I think Rust could learn from them. Especially on the ergonomics side. Otherwise, what Rust might currently do is blazing a trail through a forest.
I left my damn season 1 DVD's at my ex's place...
I don’t know how people find firefox slow. In a straight a to b test maybe, but its never a straight test. Its the test of chrome loading ads or using a crummy ad blocker, vs firefox with ublock origin. The latter will blow the doors off anything on the market.
Starts off as a thought provoking comparison and then suddenly becomes a politically driven doomsday prediction.
How Elon Musk Went from Superhero to Supervillain
I would find it easier to read with more sensible, non-abreviated variable names.
I bought the Google Play version and can confirm it's not the same as the F-Droid one.
It's a decent model.

I actually wanted to support osmand financially, only at the time the only way I could find to do so was through the play store, which I didn't want to use.

I've tried the simple apps and they are ok, but there are so many good alternatives on fdroid they don't stand out in any way.
Unit testing doesn't account for many lines in the Linux kernel. I see 33 test suites.

$ find include/kunit/ -type f | xargs wc -l --total=only
2418
$ git grep -lE '^kunit_test_suites\(' | xargs wc -l --total=only
17838
When you read software engineering books like Clean Code, they are generally heavily in favor of writing good comments.

When you read programming books, like "Learn Language XYZ" books, there are generally no comments whatsoever because there is no need. Which makes sense in the scope of such books, but I think it accidentally sets a precedent for eschewing comments in the minds of many.

But.

Out in the "real world?"

I'd say 90-95% of coders don't comment a damn thing. At least that has been my experience working in the industry since the 90s.

Some coders are in the obnoxious and toxic "code should be self-explanatory" camp, which is objectively dumb. Code can't explain intent, such as business rules or weird shit you're doing to work around weird shit in external libraries or APIs or hardware bugs.

A greater number of coders are of the mindset that inline comments are bad and that things should be explained in the commit message and/or pull request. This is more noble, but I think it is not nearly as practical as inline comments for a variety of reasons.

Many coders also believe that comments make code harder to read. I find this baffling and dumb. Get a bigger monitor or get an editor that lets you collapse/hide comments with a keystroke.
So, I've heard it said in another topic on `Topics` that a single list of topics, as far as it is an identifier for a specific person, is far less accurate than a tracking cookie (or similar technology).

Well, yes, maybe that is the case _right now_, but these are convenient arguments to push the technology through. There is nothing inherent to the technology that would prevent the `Topics` from being split such that 8 billion (current world population) unique combinations of topics exist.

If all topics are completely orthogonal to others, such that the existence of one topic for some user does not give extra information of another topic existing for the same user, we would expect a list of log2(8 billion) ~= 33 topics to suffice as a unique identifier for each individual user, _reported by the browser to every single website that is visited_.

So... obviously there is no technological limitation to this list of topics, it is completely feasible to design a list of 33 (or a little bit more) topics in this way.. so what will keep Google from not introducing more topics (as time goes on and people become accustomed to this feature)?

My point, in the limit, potentially a few years from now, this feature will be "pareto-dominant" of tracking cookies, or rather in all aspects better at tracking users than tracking cookies ever were.
I didn't even know anyone had attempted this, that's really interesting - thank you for posting the links.

In my statement you quoted above though, I was referring to the accessibility of components built using JS libraries. They introduce so many new moving parts, taking into account how every browser, OS, screen reader, other assistive tech, and all combinations of each will work is tremendously hard _without any JS_.
I'm not sure why the comment above received downvotes (I don't have enough karma to downvote). I agree that perhaps the term "reducing function" isn't entirely accurate.

However, it's worth noting that transducers aren't strictly about sequence-to-sequence transformations. From its inception, the Clojure standard library was built upon the `seq` protocol, and all its collection functions were constructed using this protocol. If it were possible to implement the `seq` protocol on channels, it would address the issue. However, it's not feasible. When querying a channel about its next element, the only honest answer is, "I can't determine that without potentially waiting indefinitely until the next message comes in or the channel closes." Turning the `seq` protocol into an asynchronous IO-bound process would be problematic. This is why transducers are essential.
This link should be visible: https://education.github.com/pack

Short answer:

- Free GitHub Pro

- A few hundred bucks of free credits on DigitalOcean,
Azure, Heroku

- A few different free domain registration offers

- A few coding courses

- Some other software and SaaS at no cost
Batteries and inverters would be common in most installations, surly?
I've always felt like it was a bad first language because there's all of this type stuff going on under the hood that isn't really hidden from the user. I think go/java are probably better first language because they're more explicit with the typing.

Java in particular, because the fact that it's so verbose and has so much boiler plate, I think, is actually good for a new programmer.
I left before the acquisition, and then re-joined the team formally known as Cobalt at Sun in 2002. I don't remember Thomas, but it has been a long time. I worked remotely, so unless I worked directly with someone I was not likely to know them.

Also, it was the Cobalt Qube :)
Hawaii's Experiment with Split-Rate Property Taxation
> The people who develop popular software like one of the functions in bash I use for free probably aren’t hurting for work I’d imagine.

I wouldn't assume that; I would donate what you can. I've been to two pay-what-you-can theater performances recently. How can I not give those people - who value every dime, who many others stiff, and where you know 100% goes to a worthy cause - more than the corporate productions, who couldn't care less about me or community and where the money goes to some billionaires and shareholders who couldn't care less about art and look forward to AI and cost-cutting layoffs. The last thing I want is the local artists, who do it for the art, to not see people's love and appreciation or to stop.

Around 5-10 years ago, IIRC the maintainer of a relatively well-known Linux distro moved home to (Minnesota?) because they had no health insurance and couldn't afford the Bay Area (or something like that, my memory is sketchy).

Also don't forget the sh-t-ton of abuse open source maintainers take.
Enabling coverage-guided binary fuzzing on macOS (2020)
Would you give back the ~1 degree we gained over the last 100 years for the standard of living we had 100 years ago? Most people wouldn't take that trade, yet I see a lot of people advocating for economic de-growth or decreasing life standards over the next degree... Personally, I'd rather take the next degree and fly around the world. In 100 years, if those 2-3 degrees becomes an actual problem, everyone will have AC, everything will be electric, and the climate will be back on track for another ice age.
If someone does happen upon your password, they probably won't also have your 2fa. That's how I view it. Safety in layers.
Java is king. Take away all the AI batch stuff and Python would shrink more. Putting python in production for online applications has many issues (trust me, I know). Java is very robust, performs well, tons of mindshare, pretty good frameworks (Spring Boot, Quarkus), and very good IDE support.
This exactly.

Sure Async Rust requires you to learn a few new things, but the blog post is mostly a rant from someone not very familiar with the topic (like what you'd expect from something called “<X> is a bad language” TBH).
winpopup was a GUI interface, `net send` was the CLI command (with which you could indeed message an entire domain)
Well, yes and no.

Imagine a company where the engineering culture hires macho programmers who love bitmasked flags and manual memory management, and who think memory safe languages and json are for sissies.

Imagine they hire lots of graduates who've never worked elsewhere and teach them that their way is best, and everyone who says otherwise doesn't understand real performance. Those 'industry best practices' are written by javascript folks who think a 2 second pageload is fast, and a 200ms pageload is instant, don't you know?

And imagine when they make experienced hires, they look for people who have experience with bitmasked flags and manual memory management - which is reasonable enough, they gotta be able to code review that stuff and coach junior employees on working with it. But has the side effect experienced hires won't rock the boat.

Now, the nontechnical bosses can ask anyone from the highest engineering leadership to the must junior of peons, and they'll all agree that bitmasked flags are the right way of doing things.

Is it so unreasonable for nontechnical bosses to trust the consensus of their engineers on matters of engineering?
Rust has exceptions. They are used throughout the standard libraries to report some errors, and as far as I can tell, they are deeply ingrained into the default testing framework.

As a rule of thumb, languages that loudly claim not to have exceptions actually use them in some way (see POSIX C, Perl, Go).
Wasn't he wrongly convicted by KKK-sympathetic southern white jurors? The /pol/ narrative tends to ignore consensus on reality.
I like the simplicity. Anything to keep people going helps. This is a nice addition
Although the 11/70 had primitive mmu support, V7 ran on the /45 and /55 and did not use anything besides I/D separation.
They solved the separation issue by homogenizing the milk: https://en.m.wikipedia.org/wiki/Homogenization_(chemistry)
It’s also a mistake to think the current administration’s White House staffers set decades of defense and foreign aid policy.
or because people develope for chrome and skip testing on other browsers.
OCaml or F#?
I actually think removing ~ was a mistake.

a) A lot of code ends up littered with Box anyways, which frankly isn't any more readable since "Box" doesn't tell you anything until you already know what it is and once you do it's just verbosity.

b) As I understand it, Box gets "special treatment" by the compiler/type system, so pretending it's just a pure standard library component is a bit obfuscatory

c) Heap allocation and heap pointers are first class citizens in other languages, why wouldn't they be so in Rust?
I think it's: 1) might not be on-demand, so then your hot fill might not be hot at the right time; 2) if it is hot, it will almost certainly be <70C, which is typically the max cycle temp.. so you either can't have that or still need a local element to get it there; 3) even if it's hot enough, you also need cold fill, so you can mix and get the temperature(s) you need.

Frankly I think even with some assumptions about your market to ignore 1 & 2, 3 alone makes it more complex than just taking a cold fill and heating to temp within the dishwasher. I believe the very few models that do have a hot fill do it on an eco basis (you already have hot water use it here too) but the validity of that is disputed, and really the only obvious benefit is to the EPC sticker (characterising energy performance) which will appear best in class (the class of all dishwashers) just by not having a multiple kW heater, not accounting for that having been offloaded to the boiler.
> even if I do get frustrated with mind-numbing Async issues from time to time.

A noticeable portion of async issues come from the fact that a lot of people use Tokio's multithreaded async runtime. Tokio allows you to mix async and native theads, which is both a virtuoso technical accomplishment and also a bit ridiculous.

If you use Tokio's single-threaded runtime, things get simpler.

The remaining async challenges are mostly the usual "Rust tax", turned up to 11. Rust wants you to be painfully aware that memory allocations are expensive and that sharing memory in a complex concurrent system is risky.

In sync Rust, the usual advice is "Don't get too tricky with lifetimes. Use `clone` when you need to."

In async Rust without native threads, the rules are something like:

1. Boxing your futures only costs you a heap allocation, and it vastly simplifies many things.

2. If you want a future to remain around while you do other stuff, have it take ownership of all its parameters.

Where people get in the most trouble is when they say, "I want to mix green threads and OS threads willy-nilly, and I want to go to heroic lengths to never call `malloc`." Rust makes that approach look far too tempting. And worse, it requires you to understand and decide whether you're taking that approach.

But if you remember "Box more futures, own more parameters, and consider using a single-threaded runtime" then async Rust offers some pretty unique features in exchange for a pretty manageable amount of pain.

Also, seriously, more people should consider Kotlin. It has many Rust-like features, but it has a GC. And you don't need to be constantly aware of the tradeoffs between allocation and sharing, if that's not a thing you actually care about.
Well designed battery packs have coolant running through them
“Excel databases” - this pains me
I have yet to see an ad this clever! It's 2023 and the ads I'm served are for things I already recently purchased (and don't need to buy again) or similar to something I have recently purchased or a cheap knock-off of something I have recently purchased.
It's less controversial but also not really relevant. Those kinds of reminders shouldn't be using cookies, and don't need to.
The one to watch here is the X ray telescope. JAXA previously lost Hitomi, which was a very promising mission, so hopefully this time they get to use the actual payload.
And that passes for a comment.

Google didn't write a press release that raises questions - insightful ones that I hardly ever see in other coverage - about their privacy practices and recommends competitors such as Firefox and Brave.
If you count PlugIn Hybrids, not BEV only. I don't, because there is good evidence that many people use them more like normal hybrids then EV. Then you just have a less efficient expensive hybrid.

But that's just pedantic and even if it is true, they are still very large and successful.
1. There are services that you pay for where you are still the product - true

2. There are services that you pay for where you are not the product

3. All services that you don’t pay for you are the product.

So the first step is getting people to pay for the service
Wow, J is up there in the top 50!

And under jobs, J is 0.02 vs. Rust's 0.0162. I have a better chance of getting a J job? Cool.
> Sure, you can turn it off, just like you can remove the pineapple from pizza, the pizza is still ruined though.

I like this analogy; pineapple on pizza is just like a browser that runs a crypto miner.