mkipper

So it could really be anything, e.g. bang, army, light and blind.

I've never seen a grocery store review mention how good the non-store-brand potato chips or chocolate bars are. I _do_ see reviews regularly mentioning the quality of produce and meat, which stores do have some control over. I think most people who take the time to go to Yelp / Google Maps / whatever and leave a review are aware that they're reviewing the store and not their Mars bar.

The experience using an app is completely different. Here's my dumb analogy.

You're browsing the snack food aisle in the grocery store. You really want a Mars bar, so you pick one off the shelf and go to put in your basket. As you're picking it up, a voice asks you from the heavens: "How much do you like this?"

How much do I like what? The grocery store? The Mars bar? Being asked the question at all?

My guess is that most people leaving 5 star reviews for the Apple Podcasts app had a similar experience. If you just finished listening to a 2 hour podcast that you enjoyed and are greeted with a "rate your experience" pop-up after unlocking your phone, you might be inclined to select 5 stars without thinking about what you're actually rating.

Is this some dark pattern from Apple added to pump up their app ratings? I have no idea. But I do think that the lines are very blurred, intentionally or not, in something like a podcast app. An app certainly _could_ mislead its users into leaving positive reviews.

Tesla publishes their own data for the safety of autopilot, which I presume is based on their own analysis of accident records. Is this same detailed information available to other groups (insurers, NIST, etc)? Or do they just calculate an aggregate "Tesla mile per accident" rate that is a blend of the great autopilot rate and horrible human rate?

I'm not trying to be facetious here. I have no idea if this data is available to any groups other than Tesla themselves. And if so, do they publish those numbers?

I did countless science labs throughout school, and they all followed the scientific method: We were given a question, formed a hypothesis, performed experiments, analyzed the results and evaluated the correctness of our hypothesis. But this was never really described as the scientific method, or presented as some general framework you could apply to things in your life. It was just the series of steps you had to follow in science labs.

Now, some kids might be able to bridge the gap between this process and the facts they read in textbooks. When you're presented some fact in biology class, it's because people have followed that same process iteratively to reach that conclusion. But in my experience, bridging that gap was left up to the student. Some kids figured it out, but I'd wager that most didn't.

One of those toolchains is used to build the bootloader, kernel and majority of userspace software for the devices. The other toolchain is used to build an I2C temperature sensor driver that was rewritten in Rust so someone could put Rust driver experience on their resume.

Dismissing this and saying "suck it up, this is the price of progress" is fine. But it doesn't change the fact that this could be a giant PITA for people making devices and developing the BSPs for them while providing almost no value. I'm not trying to argue that appeasing this group is important enough to totally reject Rust from the kernel, but as a maintainer, making life difficult for a huge number of kernel users is probably something you'd like to avoid.

I think a lot of this will come down to how Rust patches are reviewed and accepted. If Amazon or Facebook want to upstream some new Rust driver they wrote for their own hardware, there's probably no negative impact to anyone by merging it. But I'd expect maintainers will be very hesitant to accept patches that touch existing drivers. I guess time will tell.

This is survivorship bias stretched to a pretty crazy extreme. I'm pretty sure you could make a much larger list of differences in the evolution of the web and web3 than similarities.

I don't live in Banff and I'm sure there are issues with this system, but it seems pretty reasonable. Service workers would definitely be priced out if every condo/apartment was owned privately and available as a short-term rental.

Jobs are externally visible. You can see them easily (e.g. systemctl list-jobs), and systemd provides an interface for them over D-Bus[1]. There's no similar interface for anything called a transaction.

From the documentation that does mention transactions, it sounds like transactions are internal to systemd. When systemd starts a unit, it works out the dependency graph and spins up a job for each unit that need to be started before the originally requested unit can start. That would all be considered a single transaction, but it might spin out into dozens of separate jobs that get queued up.

As an example, when systemd starts on boot, all it really wants to do is successfully reach some target (e.g. multi-user.target). systemd starts from there and works backwards, building a dependency graph with every single unit that needs to start up as a part of the boot sequence to reach that target. You could probably consider that a single transaction, but the full dependency graph would probably pull in hundreds of jobs.

I don't work on systemd or anything so this isn't canon.

[1] https://www.freedesktop.org/wiki/Software/systemd/dbus/

What fraction of apps actually use sysexits.h? 0.1%? 0.01%? If an application fails and exits with some >1 error code, it would be insane to assume it's following this convention.

Hopefully the command's documentation describes the error codes (either referencing sysexits or explicitly listing the non-standard exit codes), and if it doesn't, you'll be stuck looking at the source code anyway.

I can't believe people are actually comparing telemetry in Windows to Linux.

  bail_string1:
    CFRelease(string1);
  bail_string0:
    CFRelease(string0);
  bail_array:
    CFRelease(arrayObj);  
  no_bail:
    return thing;

As an example, you may want to create a kernel module that can be configured through the device tree (e.g. binds to an arbitrary SPI/I2C bus, requires hardware-specific config). You can add a node for your module to the device tree and assign it a "compatible" property, which is just an arbitrary string you define to represent your module. If you then make your module export the same string using the MODULE_DEVICE_TABLE macro, the kernel will figure out that your module is the one that implements that node in the device tree, and it will call your module's probe callback to initialize the module, passing in the context from the device tree node (e.g. you can get a reference to the SPI/I2C bus hosting your device).

As I understand it, this is the standard way to implement drivers for devices that sit on buses that don't support automatic detection (e.g. not PCIe / USB).

This isn't a snarky RTFM comment. The usage model file in the kernel documentation gives good motivation for what device trees are used for and their basic structure, and the APIs to pull data from them are straightforward enough that you can probably figure them out by looking at an example.

Content creators could move to a different platform, but that's also incredibly risky. Unless you're already hugely successful, abandoning YouTube probably isn't a great way to build a following. The same goes for building their own platform, with the added complication of it being prohibitively expensive to make a scalable, relatively ad-free video platform if you aren't a megacorp who generates billions of dollars from other revenue streams.

So I suppose there is a risk, but it wouldn't surprise me if it's a risk that Google would live with if sponsored content was undermining their entire monetization plan for YouTube. I have no idea if they'd care enough to do this or not, but I don't think a scattered collection of content creators have enough leverage to scare Google here.

On the other hand, the government potentially has a lot to lose if domestic companies are completely unable to produce hardware needed for critical infrastructure. The government also benefits from these companies expanding their supply chain to include domestic production, so the companies are asking the government to provide enough capital/tax breaks to make domestic production viable, and they're trying to convince the government that this provides enough value to the USA for it to be worth it.

But this is being pushed by lobbyists paid for by giant corporations, so it's fair to be skeptical. In reality, the $50B number probably sits somewhere between "the bare minimum needed to make this viable" and "a handout pocketed by greedy corporations".

That's great for some people, but looking at everyone else, I'd imagine there's a split between people who _only_ have meaningful social interactions at work and people who just happen to _enjoy_ it.

1. Unprecedented for "average" engineers (i.e. not leading their field) until very recently

2. Offered by extremely profitable big tech companies or less profitable companies with giant pools of funding

3. Offered by companies that highly value software engineers

4. Offered in extremely competitive markets

The vast majority of employers in Germany, and in most of the world, don't meet those criteria. It's unreasonable to compare the average German tech company to the best paying American tech companies.

Compared to the best paying software jobs on earth, German tech pays pretty badly. But so do most companies. I used to live in a city with a population of ~1 million, and most local "tech" companies paid new grads $60k - $80k, with senior developers landing between $100k and $150k. That's much closer to Germany pay than Silicon Valley pay.

Not to mention plain ol' inertia. The vast majority of people compiling the kernel are using GCC. Switching to a different toolchain or maintaining two toolchains (assuming there are no subtle ABI issues between a GCC kernel and LLVM driver) isn't necessarily trivial, and requiring that just to build a single driver might rub some people the wrong way. That's not a _problem_ with LLVM, but it is an inconvenience.

I wouldn't normally associate it with a particular connector, although I understand it's a pretty commonly used that way in the PC community.

The OS kernel for nearly every PC and server on earth is written in C.

Almost every electronic device on earth complicated enough to require software is probably running at least some firmware written in C.

I think those both outnumber ATMs by a hefty margin.

I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

Why? I have no idea.

RH is getting sued for market manipulation. This is the inevitable result from that. RH may very well be guilty in all of this, but not for these margin calls.

The programming languages are all defined in IEC 61131-3, and you can more or less use them interchangeably. You can use structured text for (clunky) text-based programming, ladder logic if you want to feel like an electrician in the 70s, or functional block diagrams if you like flowcharts. They each have pros and cons, and being able to use the different languages (with different paradigms) in a single application is one of the more interesting things about PLC programming. There are probably good textbooks for this, but I don't know of any.

PLC programs execute in a constant loop (scan inputs, execute program, set outputs), so basic programming problems (e.g. delaying execution of some function) often require some re-thinking on PLCs. Having a basic understanding of how a PLC actually executes your code is pretty critical. Again, there are probably textbooks for this, but if you buy a physical PLC, its datasheet might also explain this.

You'll need to connect the PLC to some hardware for it to do anything meaningful, so having a basic knowledge of electronics would be useful. If it's just a hobby, you probably wouldn't need to know any more than you would if you were working with an Arduino.

There aren't that many major PLC vendors, so to get started, you could by an entry-level PLC from one of the big players (e.g. Allen-Bradley Micro800 series). Admittedly, I haven't looked at PLC options in 5+ years so there might be better options these days. Unfortunately, PLCs are pretty pricey, and even a small one will probably set you back a few hundred bucks. There are probably simulators available if you're just curious about PLC programming languages, but I don't have any experience there.