Arch-TK

We don't have magic oil filters which last even 22k miles. You should be replacing them every 6 months / 6k miles, or 12 months / 12k miles depending on your risk tolerance (some people suggest even half my short interval).

Anyone who actually drives their car regularly will be doing an oil change at least twice a year. If an oil change takes more than 30 minutes of actual labour time of an inexperienced mechanic, it's going to be a serious financial burden which will likely outweigh any 2mpg improvement.

Repair shop owners also don't enjoy work which is unnecessarily difficult.

Between rebuilding an engine and disassembling a bumper to replace a lightbulb most mechanics would genuinely rather be doing the lengthy but interesting work of rebuilding an engine than the lengthy and fucking boring task of disassembling a bumper to fix a lightbulb.

Moreover, even if a mechanic must charge you stupid amounts of labour cost to do a simple repair because it genuinely takes that much time, the customer might not come away with it thinking: "fuck, I bought a dumb car which is expensive to repair", they might instead come away with it thinking: "all these mechanics, quoting ridiculous prices to fix a light bulb, they must all be scammers".

EVs also have consumable parts which it would be incredibly annoying to place in nonsensical locations.

The obvious one is the battery, and you can argue that modern EVs have batteries so expensive that when they are dead the car becomes scrap, and - sure, whatever.

But EVs still have: cabin air filters, coolant, brake fluid, lubricants in various places (although granted, these lubricants will mostly last the service life).

At the end of the day, as long as you have a car which moves, and not a statue, it will have things which wear out and which should be easy to replace.

Engine oil and oil filters are just an example.

A real squirrel would need acorns, I would assume it's a clockwork squirrel too.

My point was, if you enjoyed it when it was tinkering heavy, nothing stops you from continuing to enjoy that even if there are now plenty of printers that don't require it.

I don't quite get your point about 3D printers.

I spent many months redesigning, improving and rebuilding a prusa clone, not because I couldn't afford anything else, but precisely because I could afford to "waste" time and money learning and having fun.

Once I felt like the printer was in a useful state, I spent some more time getting it to a point where it could print nice ABS parts for a Voron Trident. Of course I couldn't just build a Trident. That would be too easy. Before I had even finished assembling it, it already had a number of bespoke modifications that I had designed.

And that's just the tip of the iceberg. Have you ever _looked_ at the klipper source code? It's like a fractal of weirdness. I mean it works, and clearly the person behind it is very knowledgeable about many things. But it makes for such an enormous and fun playground for improvements and redesigns. I've redesigned the entire build system for the firmware component. I've made the host component an actual (almost) normal python package. I changed a bunch of core aspects so that it could be packages for a linux distro. I am working on making the native helper a normal python native extension library too. And I am also writing some proper test rig for it.

And while I was at it, I started writing my own display software which doesn't use Wayland or X. It is going quite well actually. (Writing it in Rust)

This hobby (and, really, any hobby) has as much depth and obscurity as you are willing to look for.

The criticism is not of the idea that the world has problems, and that we should look at those problems with the aim of fixing them.

The criticism is of the assumption that a world without problems theoretically could exist.

You may disagree, but you will not find a definition of such a world that everyone can agree on.

Regardless, of whether you agree (that such a definition doesn't exist) or not, if you do plan on bringing about such a utopia, and you begin to meet resistance, the question you will inevitably need to answer is: How do those who resist fit into this utopia?

The historical answer for this question, which by all appearances seems like an inevitable answer, is the reason why people criticise utopian thinking.

2.20 seems ... weird?

No matter what I do, the clock line in the log stays at 1 during tests.

Also the D latches behave very weirdly.

This was my point.

More straw man arguments. You have just confirmed that you have _no idea_ what alternatives exist, that you have _no idea_ what systemd actually does, and you have _no idea_ what my actual stance is in this discussion.

Please don't insult me by insinuating that I think that sysvinit is anything other than a weird esoteric init program which has, in the past and on linux distros, been the supporting piece of a garbage heap of poorly written shell scripts (and which is currently on BSDs the supporting piece of a relatively okay designed heap of shell scripts which implement a silly service management model that I also don't like).

Most of systemd's proponents are not people that care about what service management system they use. They defend systemd despite their ignorance of both systemd and the proposed alternatives solely to feel part of the "in group" of people who moan about people who moan about systemd.

The word was "declarative" not descriptive.

There is nothing descriptive about `Wants`, `Before`, `After`, `Requires`, `Requisite`, `BindsTo`, `PartOf`, `Upholds`, `Conflicts`, ... we could go on. And we can stop there. (To clarify, _I_ know what these all mean, but certainly I didn't have a clue what they meant until I read the docs about and didn't fully understand the nuances of these until I re-read those docs many times and read the source code.)

But the "declarative"-ness of systemd's configuration files can also be put into question when it's incredibly common to find an `ExecStartPre` containing a shell oneliner.

That being said, my goal was not to start a discussion about systemd here. My goal was to call out the completely unproductive strawmanning of systemd critics by the person I was replying to.

There are ~three groups in the systemd debate.

People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).

People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).

And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.

The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).

Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?

By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.

It's incredibly common for people talking about C online or even in books (be that blog posts, side notes, tutorials, guides) to constantly make mistakes like these.

C seems to be one of those languages where people think they know it based on prior and adjacent experience. But it is not a language which can be learned based on experience alone. The language is full of cases where things will go badly wrong in a way which is neither obvious nor immediately evident. The negative side effects of what you did often only become evident long after you "learn" it as something you "can" do.

If you want to write C for anything where any security, safety, or reliability requirement needs to be met, you should commit to this strategy: Do not write any code which you are not absolutely certain you could justify the behaviour of by referencing the standard or (in the case of reliance on a specific definition of implementation defined, unspecified, or even (e.g. -ftrapv) undefined behaviour) the implementation documentation.

If you cannot commit to such a (rightfully mentally arduous) policy, you have no business writing C.

The same can actually be applied to C++ and Bash.

Some people have some bizarre obsession with having absolute and total control over the placement of every single last character in their document while simultaneously not caring about the fact that this placement is sometimes not reproducible and randomly becomes diseased.

My most memorable MS Word experiences are all the times I accidentally put my document into a weird state and didn't notice something was wrong until I've spent 3 more hours on it, at which point I was forced to re-create the document by copy pasting text into an earlier copy.

And the only reason I knew something was subtly wrong was because the weird VB extension I was required to use would stop working correctly. Basically this would happen when some random key element of the document had ended up with a very subtly different style. If I didn't have to worry about the VB extension breaking, I'd just have a document with some weird bug somewhere.

If I wanted a professional looking document, I would use some modern LaTeX variant maybe with Pandoc to generate most of it from something more restricted like Markdown.

If I wanted total control over the content of a page, I would use some kind of graphical publishing software with text and vector graphics.

I have zero idea what kind of Stockholm syndrome you must have to think that Microsoft Office (or any other similar WYSIWYG editor for that matter) is power user software.

It has lots of features, that's for sure. But the features form a Jenga tower. That makes it a toy.

FreeBSD and OpenBSD docs are great, but let's not say they're the pinnacle of docs. I like them a lot more than docs for the average Linux distribution. They're even more polished than Arch Linux wiki. But they still have room for improvement. And improving the Arch wiki is easier in my experience.

You are either talking about a license nobody is using (at least I've never heard of it) or misconstruing what the AGPL obligates you to do.

I am going to assume it's the latter.

If you in your house take an AGPL program, host it for yourself, and use it yourself, nothing in the AGPL obligates you to publish the source changes.

In fact, even if you take AGPL software and put it behind a paywall and modify it, the only people who the license mandates you to provide the source code for are the people paying.

The AGPL is basically the GPL with the definition of "user" broadened to include people interacting with the software over the network.

And the GPL, again, only requires you to provide the source code, upon request, to users. If you only distribute GPL software behind a paywall, you personally only need to give the source to people paying.

Although in both these cases, nothing stops the person receiving that source code from publishing it under its own terms.

The US could be be such an amazing place...

Meanwhile the solution to this problem in the UK is to reaffirm that you are in fact guilty by default unless by happenstance you are determined not to be by an unfairly chosen panel of blind and deaf mice.

I can't see such a GrapheneOS existing without explicit Google support. And I don't think Google would support something like that unless they suddenly decided to actually not be evil again.

GrapheneOS currently doesn't ship Play Store or Services OOTB. They install as normal apps (albeit with GrapheneOS providing support code to make the fact that these things use/expose custom privileged APIs work correctly). I don't know if the Google TOS would prohibit that, at least I am not aware of any enforcement action against GrapheneOS in this regard. GrapheneOS also doesn't have Google's blessing, meaning some apps like Google Pay won't work on it. To get this, you need to apply to be an OEM.

Really Motorola doesn't need to sell a GOS phone. Motorola just need to sell a phone with the right hardware security features, open source/upstream their Android/Linux patches, and give users the ability to run GOS.

Hopefully they can then give you the option to buy one with GOS preinstalled, but even if they don't. It will be sufficient that it can run GOS.

Unlike Windows, nobody feels they're paying an inherent tax when buying a stock Android phone. I'm sure nobody will mind.

The hard part will be actually supporting the phone for long enough.

GOS is reliant on Google's open sourced Pixel android releases up to and including the 9 series. This is because GOS doesn't have the resources to handle that entire side of things. But I guess part of that is also that GOS doesn't have access to the necessary information to do that stuff properly either.

Google's hardware is just hardware. It is not locked down like the hardware of many other manufacturers. Moreover, it's the only such hardware which also allows you, the user, to lock it down for your own security. GrapheneOS is not just focused around avoiding Google, it's more accurately focused around security and user choice.

The goal is to give you the option to avoid needing to rely on Google's spying or services while not having to compromise on security.

None of these other solutions regularly get included in Celebrite's documentation as being an explicit benchmark of their software's ability to break into phones. And that's almost certainly due to the fact that unless you leverage hardware security features like what GrapheneOS (and stock Android on a Pixel, and iOS on an iPhone) utilises, you have no chance of going against any actual adversaries.

And I'm not just talking about state actors here, even drive-by opportunistic attacks are likelier on a random other phone running some other Android build.

So yeah, you are running Google hardware, that doesn't make you "googled". It's just a sad reflection on the reality of the hardware landscape. If you want the same security as what GrapheneOS offers, you will currently need to use a Pixel.

I'd be curious to see what comes out of their Motorola partnership though.

If you have something which doesn't come with such a function, nothing stops you writing it?

The C language has no such concept of attribute destructor and I am not talking about attribute destructor.

I just mean, in the simple English sense, a function which exists to deallocate a structure.

Unfortunately doesn't work if the project you work on squashes everything :(

If you have something which contains pointers, you should have a destructor function for it, which itself should check if the pointer is not NULL before attempting to free any fields.

Imgur isn't blocked, they are blocking the UK. It has to do with their infractions regarding the GDPR. They blocked the UK to avoid getting fined any harder.

Google doesn't have any magic way to do instant notification that nobody else has access to. The only thing they have access to in this regard is disabling any battery optimisations without triggering warnings.

Notification and battery performance is on par with google's solution except when an android build does dumb things to prevent the background activity, in which case notification performance gets worse and battery draw gets worse (not sure why exactly, it's just a common issue in these regards).

Why does an electric car need a flappy paddle gearbox?

But that's the point. DRM works at all (in terms of causing inconvenience, not preventing copying, for that it will never work of course) because the people producing the data have an interest in applying the DRM.

But the people producing 3D printable gun parts are _not_ interested in applying the DRM.

If you want to draw an analogy to media, this is more like if the government mandated porn detection software on your computer which would prevent porn from being able to be displayed on your screen. Or mandating HDCP between your monitor and your computer so that your computer could implement restrictions on what you could view on the monitor.

Except that computers are extremely difficult to DIY from basic components (I mean raw chips and metal). Meanwhile I can literally buy aluminium extrusions, or even bits of wood, some stepper motors, some gears, some belts, some pulleys and some stepper drivers, an STM32 devboard and get PCBWay to make me a simple PCB, or just use a prototyping board. And at the end of it, I would have a high quality (maybe a bit slow) 3D printer. I can tell you with absolute certainty that it could print gun parts because I have personally taken a trash-tier prusa i3 mk2 clone and turned it into a machine which could probably rival the mk3 at least.

How exactly are they planning on stopping me from designing a part, slicing it, and then putting it on a DIY 3D printer?

They could maybe achieve this by restricting the sale of certain components such as hot-ends, extruder gears (although you can get away with generic gears), or stepper motors and stepper motor drivers. I just don't see it happening. Maybe they could ban open source slicers and CAD programs?

But I guess I better start stocking up on high quality stepper motors and stepper motor drivers and buy a milling machine and a lathe so I can manufacture the other parts myself. You never know when the UK government will steal another wonderful authoritarian idea from another country.

EURion marks are a feature you must include on your banknote for it to even be considered real. And it's _one_ feature. It's relatively trivial to make a chip which can detect their presence.

On the other hand, if I need a replacement part for something, it's unlikely I will find the manufacturer giving me models for it. And if a manufacturer is giving me models for it, they probably do so with the explicit expectation that I might end up using them to manufacture a replacement.

In most cases either me or some other volunteer will need to measure the existing part, write down all the critical measurements, and then design a new part from scratch in CAD.

Even if somehow you are able to fingerprint on those critical measurements, that's just _one_ part.

The only way this kind of nonsense law could work is if you mandate that 3D printers must not accept commands from an untrusted source (signature verification) and then you must have software which uses a database to check for such critical measurements, ideally _before_ slicing.

Except that still doesn't work because I can always post-process a part to fit.

And it doesn't work even more because the software will need to contain a signing key. Unless the signing key is on a remote server somewhere to which you must send your model for validation.

This is never going to work, or scale.

There are even more hurdles... I can design and build a 3D printer from scratch and manufacture it using non-CNC machined parts at home. A working, high quality 3D printer.

Where are you going to force me to put the locks? Are you going to require me to show my ID when buying stepper motors and stepper motor drivers?

What about other kinds of manufacturing (that these laws, at least the Washington State ones, also cover)?

Will you ban old hardware?

What about a milling machine? Are you going to ban non-CNC mills?

These are the most ignorant laws made by the most ignorant people. The easiest way to ban people from manufacturing their own guns is to ban manufacture of your own guns. But again, this is a complete non-issue in the US where you can probably get a gun illegally more easily than you can 3D print something half as reliable.