mfuzzey

>Why shouldn't the public be able to elect whoever they want?

Because some types of illegal behaviour of candidates can influence the vote.

This isn't about a court banning MLP because of her views or policy proposals (that would be very bad) but because she has been show to have comitted fraud by abusing EU money to pay for her own party.

Unlike in the US there are strict rules in France about how much politicians can spend on campainging and where the funds can come from that are intended to ensure a level playing field rather than favouring rich candidates.

If courts couldn't ban candidates who don't respect the rules then elections could be "bought" illegaly.

why? Serious question - as a European I'm really baffled by the US these days?

In the tablet / phone world where end users expect to install applications from the playstore yes but there are many other device types that do use AOSP.

For instance some parking meters / train ticketing machines / payment terminals run Android. source: I work for company that makes some of them though we are moving away from Android to more classical embedded Linux.

Google play services doesn't matter in these contexts.

While non software people certainly don't understand data structures etc themselves I'm sure they get the idea that software has to be designed, just as they get that most buildings (like larger than a shed) have to be designed by an architect before construction people actually start building it.

Most / all of software work, including coding, is actually architecture / design (at varying levels of zoom) the equivalent to construction in buildings is fully automated in software (compilation etc)

> What changed in software in the last 20 years

Backends handling tens / hundreds of thousands or more of concurrent users rather than locally deployed software on a single machine or a small server with a few 10s of users?

Mobile?

Integration with other software / ecosystems?

Real time colaboration amoung users rather than single user document based models?

Security?

Cryptography?

Constant upgrades over the web rather than shipping CDs once a year?

I'll pass on AI for the moment as it's probably a bit too recent.

There's a big difference between obeying laws (which all companies pretty much have to do if they want to stay in business) and voluntarilly aligning with what they think a new president wants without there being any specific law forcing them to do that.

I actually think the business reason FOR the DEI stuff (to appeal to customers by coming accross as fair and progressive) made more sense. Have the customers really changed their minds just because someone else is in the Whitehouse?

Some abuse of wealth for political power may be inevitable but some countries are a lot better at limiting it than others.

For example here in France the amount of money politicians can spend on campaigning is strictly limited (and reimbursed by the state for those that pass a certain threshold of the vote). I'm not saying that it's perfect or that abuse doesn't sometimes still occur (as the current court case involving ex president Sarkozy shows) but I think it does improve things a lot.

Contrast that with the American system where to have any chance of becoming president (no matter which party you support) you basically have to be rich. And where multiple lobbyists and special interest groups basically buy the policies they want...

Companies obeying new laws is one thing, and of course they don't really have much choice about that if they want to stay in business.

But companies changing stuff just to cozy up to a new president without there being a law forcing them is quite another thing.

I think this sets a dangerous precedent, regardless of the stuff being changed.

And that is exactly what we don't want. We want civilized law based international relations not a jungle.

International courts should settle disputes based on law

It's not quite the same. The EU has banned those companies from supplying network infrastructure. That infrastructure is used both by private individuals and by companies, ministers etc. AFAIK they have also banned TikTok on official government phones. However they have not generally banned TikTok for everyone.

To me this makes more sense since a back door in network infrastructure allowing governement communications to be intercepted is far more serious than some kid using TikTok.

> lead people to believe that humans are getting nastier over time, even when they’re not

Most people aren't nasty or getting nastier but nasty people are likely over represented in those with power and there seems to be a current swing to having more such people getting into positions of power.

Added to that is that modern technology and weapons make it easier for a few "bad apples" in power to cause more grief to more people than before.

Agreed with your point of accessibility to people who don't live in the code.

But that doesn't preculude documentation near code nor Markdown. It just means that you need a CI job to publish the doc stored in the git repo as (for example) HTML or PDF.

For diagrams stuff like PlantUML are great, edit as text, publish as images.

I haven't seen such problems on Debian or Ubuntu guess it's par for the course with a bleeding edge distro.

The author seems to be focusing on the disk space advantage and claiming it's not enough to justify the downsides today. I can understand that but I don't think disk space savings are the main advantage of shared dependencies, rather it's centralized security updates. If every package bundles libfoo what happens there's a security vulnerability in libfoo?

One of the issues with user replaceable batteries is waterproofing (IP rating).

My first smartphone was a Samsung Galaxy S1. It had an easilly swappable battery which was great because time between recharges was much shorter in those days so I had 2, one in the phone and one in the charger.

But once I got the phone wet just using it outside in the rain. After that it refused to charge for several days until it dried out.

More recently I've dropped my phone in water and it was perfecty fine with no drying time at all...

ACPI / UEFI is heavily used on ARM server systems.

Embedded stuff mostly uses u-boot true. But u-boot itself is actually fine for this type of device. I recently did an evaluation of several system on modules. They all came with their own usually different version of u-boot. For the purspose of the evaluation I ddin't care I just pointed them at my kernel + DT and it booted.

The "decades old" part really depends. At work I've just finished updating our u-boot 2020.10 to 2024.04.

But embedded and PC / Server are fundementally different in terms of use case. On a PC / Server the user expects to install an OS of his choice. Embedded isn't like that, the definition of embedded it pretty much "single use case device" so being able to install a generic Linux distro and run libre office isn't a use case many care about, particularly if it would increase the hardware costs.

Phones are a different case to embedded, here it *would* be useful to install a generic OS (though probably not the same distributions as on PCs). For that a standarised bootloader / OS interface would be useful but it deosn't have to be UEFI / ACPI, u-boot distroboot would be sufficient https://docs.u-boot.org/en/latest/develop/bootstd.html

You don't actually need a custom kernel build for every device these days (and haven't for years). Within the same ISA (ARM32 or ARM64) you can run the exact same binary kernel on multiple devices provided you have a suitable device tree for each.

And that's not really much different in principle to APCI (which is really "DT on steroids"). The main difference is that with ACPI the device manufacturer ships the tables whereas with DT they have usually have to be provided by others.

PCs haven't standardised everything at the hardware level for years. The original PC had standard IO addresses but this only covers a few things like keyboard, display, serial ports. Modern PCs, especially laptops, have all sorts of "non standard" chips hanging off I2C busses.

There are 2 reasons it "just works" on PCs 1) ACPI tables descibe it (just like DT) 2) There are compatibility tests needed to get the Microsoft hardware certification to run Windows

But it goes beyond the kernel to the full OS distribution. All PCs have pretty much the same use cases and similar UI capabilities. Sure some may be more powerful etc but they're all pretty much the same idea. So on a PC it makes snese to pop in a USB key with a "generic" Linux distribution an install it. It probably doesn't make as much sense to want to install the exact same distribution on your PC, phone, TV and router. This means that, given the OS is going to be customised anyway there just isn't as much demand for a fully plug and play system.

This is the reason I will never use the Apple ecosystem, even if the hardware is pretty good.

A hardware manufacturer has no business telling me what I may or may not run on hardware I have purchased, period.

An example of a large code base that has survived decades and undergone huge scope changes without running into these problems is the Linux kernel.

Initially it only ran on X86 PCs and most of the hardware it supports today didn't exist. Today it runs on many architectures from small embededded systems to super computers.

Some of the initial code was pretty rough but the modern stuff is pretty good and cleanups and refactors are done all the time. Indeed long term maintainability is one of the major considerations for maintainers deciding to accept or reject patches.

Why does this work for Linux? Because companies are used for funding (the majority of kernel developers now do it as part of their paid jobs) without giving them technical control of quality. The companies paying people to work on the kernel get a say in what is worked on (presumably things important to them) but not about how it is done.

Copying isn't theft (though it may still be illegal). Theft is "dishonest appropriation of property belonging to another with the intention to permanently deprive the other of it."

So if I steal your wallet, your phone or your car that's theft because you no longer have access to it and I do.

If I copy a book, a CD, a DVD, a document or a chip the original owner still has it. That doesn't mean there's no prejudice or that it's legal but it's not theft.

Telegram has plenty of alternative clients. The others probably don't

RISC-V is only really directly helpful for those building their own silicon (sure "anyone" can implement a RISV-V core in a FPGA but that won't give you the performance of an ASIC).

If you just want to buy a chip and put it on your own board you don't really care that much about the ISA as long as the toolchain, bootloader, kernel support is there and stable (which is pretty much the case with RISC-V now).

But if you're desiging your own silicon the ability to make or modify an existing open source RISC-V implementation can give you the flexibility that currenlty only the very largest players in the ARM ecosystem that have architecture licenses have (I think that's pretty much limited to Apple, Qualcomm, Samsung).

I expect the smaller but important players like NXP, ST, TI will be bringing out RISC-V chips taking advantage of this.

ARM have also been talking about making their fees dependant on the price of the final product so that could also push people to RISC-V, not just to pay less but also to not have to jump through the hoops that would be required to provide all the information to do that.

> All the other manufacturers have really really shitty BSPs in comparison,

I disagree. The NXP (i.MX line) and the TI (am62x) and the STM32 MP1/2 all have good mainline support.

What you say is true of most of the Chineese chips and of mobile chips but if you go with mainstream suppliers targeting the industrial / automative markets these days mainline Linux support is good at the SoC level. At the SoM level some are better than others but it's not that hard to pull the approriate DTS into your mainline kernel build even if it isn't already upstream.

RPi is probably better for hobbyists but that's not due to the mainline status but a community more in tune with hobbyists than the more industrial products.

I've built professional embedded Linux systems based in i.MX5/6/8 and STM32MP1 with mainline based BSP rather than vendor stuff but have only ever used the RPi for one off tools.

Intuative for new users is often less efficient for experienced users so for many complex professional tools that will be a core part of the users' work it probably makes sense to go for the less intuative but more efficient tool and provide training.

Note the "core part" though. Even professional tools that many people have to use occasionally (say tools to book professional travel) should be intuative because someone who uses it once or twice a year will forget complex things. But it's probably OK for a CAD program used by engineers as a main part of their job to have a steep learning curve.

Using computers is now a basic necessity for life in modern societies, on par with reading and writing.

I think the answer for people who do not have or for some reason cannot use computing devices is to provide places they can go and be assisted (we have those in France called "maisons de service").

I don't think you can design everything around the lowest common denominator (in terms of language or computer literacy) but you can provide ways of obtaining assistance for those that can't manage by themselves.

Why shackled to SMS? I don't have an iPhone don't use iMessager and haven't sent a SMS in the past 10 years. Everything these days is What'sApp / Telegram / Signal

You need to get permission from your employer obviously but I think most are fine with that these days.

I'm not talking about open sourcing something your company has made from scratch and is their core product but just contributing (usually small) imporovements made to some open source used so the "giving away IP argument doesn't really hold water".

In my experience that's an easy sell to the company on purely practical / selfish terms ("we can keep it in house and have to spend time reapplying our changes to each new upstream version that comes out or we can submit it upstream and have easier updates in the future").

Look at all the companies contributing to the Linux kernel in each release, most of them do it for precisiely this reason.

That's not what I get from the article.

More that it's pointless to contrinute to an open source project if you're not interested in improving the software the project is building for a reason that matters to you. That's true regardless if you know what you're doing or not.

So if your objective is just to "get a PR merged" that's not really helpful. Rather it should be to "fix this bug" or "add this feature" because those things somehow matter to you.

The "you" can also mean your employer. So if you use some software as part of your job and it's got a bug or is missing a feature that matters enough to you then fixiing it and contributing it back is a perfectly valid and great way of funding open source. It's also not normally philantropic, because when you make the effort of getting your changes merged upstream it also reduces your own long term maintenance burden of having a private fork.

I think you and GP (about Lucas Chess) are using the term "drive-by PR" differently.

I agree with the GP's definition. I consider a drive-by PR to be one made by someone who doesn't intend to become a regular contributor to the project but does have real motivation as a user of the project to get their "itch scratched" (a bug fixed or some feature that matters to them added).

I also understand the type of PR you're describing (and agree with you that it's a bad idea) but I think it needs another term to describe it. Maybe "non user PR" or "CV driven PR" or "Vanity PR"?

(edit sp)

Are they only charging or also restricting the number of tickets available per day?

Restricting the number of tickets is probably an effective way of handling overtourism.

Just charging would probably be only be effective in reducing the numbers of tourists if the price were much higher. And then it would, righltly, be seen as unfair to poorer tourists.

I don't think a contributor can unilatary withdraw their code from a code base unless there is license change. Then it wouldn't be about "withdrawing" their code but refusing to allow it to be distributed under a different license than the one that applied when they submitted it.

So if Linus wanted to relicense the kernel under a different license than GPL2 he couldn't do it by himself without tracking down all the contributors and getting them to agree to the license change or removing the code in question which, for someting as large and with as many contributors as the kernel, would be basically impossible.

The CoC is completely different. It's not a license change but a process change. If a contributor doesn't like a new CoC or a new processs they can decide to no longer contribute in the future under that process, including no longer maintaining "their" code already in the kernel but they can't force anyone to remove it.