It is still collecting data. That is the nonstarter for me. My car does not collect any data on me. There will be no software update in the future changing any privacy policy because my car does not ever receive software updates. Even if the ECU did get an update after some repair, it is airgapped with no ability to send out telemetry. I still get certain telemetrics logging for maintenance, locally, of course, via OBD-II.
But, free software lost it's way around GPLv3. From the end user's perspective, GPLv3 says that you can only use the software if it's either a cloud service, on hypothetical open firmware devices, or if you install it yourself.
AGPLv3 partially solves the issue by blocking people like Google from using it to build proprietary cloud services that take away their users' freedom. (It still doesn't solve the problem where providers use network effects to achieve the same end game.)
I don't understand this either. The GPL doesn't address end users and their use of software at all, to be technical. It only addresses what terms of copyright redistributors of GPLed software are allowed to apply in-turn to subsequent end users.
The point of the Free in free software was always to protect the users of the software, not the vendors or the redistributors. (This is why the license focuses on the redistributors -- the mechanisms of the license limit their rights in order to protect others' rights.)
The first sentence of the GNU manifesto says this, and a few sections later in the document elaborate on the point:
Note, in particular, footnote [1] which explains that its OK for distributors to ask for payment, but that it's never OK for users to have to ask for permission to use the software, and the section "Why I Must Write GNU".
Since then, software service monopolies became common, and all of the most end-user-hostile systems on earth rely heavily on the GNU system. At this point, we're paying for permission to use those services with our money, our data, our democracy, etc.
I certainly cannot give you permission to use any of the GPLed services that I have used, or that I've been paid to extend. Therefore, I say the free software movement has lost its way.
I see your point and I agree. It's just that when you say "GPLv3 says that you can only use the software if it's either a cloud service, hypothetical open firmware devices" that's a stretch and not really true. AIUI vendors can pre-install GPLv3 software as long as they let you actually then replace the software (i.e. no DRM or locked bootloader). The firmware can still be non-GPL and non-replaceable. You just can't use GPLv3 code in the non-replaceable bootloader or firmwares.
AFAIK you can use GPLv3 for non-replaceable stuff. The thing is only to allow the users to replace it IIF it's phisically possible to do so. If you make a device that boots from a ROM it's not a problem. If you sign your updates and keep your public key on a ROM and there is no way to boot anything else… there's a problem.
> From the end user's perspective, GPLv3 says that you can only use the software if it's either a cloud service, on hypothetical open firmware devices, or if you install it yourself.
The anti-tivo clause bans things like Apple pre-installing GPLv3 software on macs, but allows them to let you use exactly the same software as long as they do not give users access to the binary. AGPLv3 blocks both use cases, GPLv2 blocks neither.
On the spectrum of "things that take away user freedom", withholding the source code is bad. Withholding the source code, the binaries and physical access to the computer is obviously much worse! This latter business model is heavily subsidized by GPLv3.
Isn’t this going to immediately become daily news?
Half the time I call a company they say “we are recording your voice for security / authentication purposes”.
The companies that do that have all the information on me that they require for me to set up an account, so their data breaches will be just like this one, but 1000x larger.
Can we just fast forward through the part where this works for ID theft, past the firefox age verification plugin that uses these datasets, and even through the part where people in the plugin dataset are digital outcasts (this voice has been used too many times. Want to try another?)
At the end of this dark predictable tunnel, maybe there will be a ban on biometrics for important stuff, a repeal of the age verification laws, and actual privacy legislation with teeth.
This would eliminate the credit report, monitoring and fixing industry, which would be a good thing.
Court records are public in the US. If creditors want to know if you’ve been in financial trouble, they should check for bankruptcies and lawsuits, not the extrajudicial version of those that the credit reporting companies run based on hearsay.
Credit reporting is better in some ways than alternative systems of “vouching” for someone.
It’s not better in all ways, of course, but the alternative is not “everyone gets cheap credit extended to them” but rather “people who rich people know and trust get cheap credit extended to them, some others get more expensive credit, and some get no credit extended”. It’s not obvious to me that that’s better.
We definitely are already in the second regime. The credit rating industry just makes sure the bottom 99% of the decision making also happens in secret.
This, and because of that, claiming your app "runs in kubernetes" is completely meaningless.
Concretely: Take your app. With one button click, or apt-get install ??? on all your machines, configure k8s. Now, run your app.
The idea that this could work has been laughable for any k8s production environment I've seen, which means you can't do things like write automated tests that inject failures into the etcd control plane, etc.
(Yes, I know there are chaos-monkey things, but they can't simulate realistic failures like kernel panics or machine reboots, because that'd impact other tenants of the Kubernetes cluster, which, realistically, is probably single tenant, but I digress..)
If your configuration is megabytes of impossible to understand YAML, and is also not portable to other environments, then what's the point?
(I understand the point for vendors in the ecosystem: People pay them for things like CNI and CSI, which replace Linux's network + storage primitives with slower, more complicated stuff that has worse fault tolerance semantics. Again, I digress...)
> If your configuration is megabytes of impossible to understand YAML, and is also not portable to other environments, then what's the point?
If almost all your configuration is about getting Kubernetes set up, and not about your application setup inside Kubernetes, there probably isn't a point. But being able to use roughly the same config inside different Kubernetes is quite good.
But I've never seen portable kubernetes configs (except for vendor software that probably wouldn't be needed outside of kubernetes).
If you just tell kubectl to dump your pod configs, then load them on some other cluster, that definitely won't work.
If you use the management software that generated the pod setup somewhere else, that probably won't work either because the somewhere else is going to be missing the CSI and CNI you targeted. Even if those match, it'll be missing the CRDs. God help you if you want to run two programs on one Kubernetes, and there's a CRD versioning conflict in their two dependency sets.
The only things that work around here are the thermacell repellents (they have a little butane fire that evaporates stuff off a mesh pad). Their effect seems pretty localized in time and space, but I wonder what's in them, and how problematic it is.
Even back then, it could play more than one stream. You had to have a sound card or kernel drivers that supported it (and all non-obsolete ones did by the time pulse audio came out).
I still don’t know what purpose pulseaudio serves, other than adding latency and making stuff less reliable.
PipeWire is better, but it turns out you can just use OSS under freebsd these days, and everything just works, but with lower latency.
If you have some sort of potato sound card that can’t mix output channels in hardware, note that OSS added sw mixing by 2007 (with support for 16 channels by default).
Sure, sure. I remember a time when I didn't have a sound card that supported it and couldn't play multiple streams at a time; this is a thing that really happened. I did eventually go out and buy a soundcard to enable multiple streams.
Nonsense - HDA systems were overwhelmingly the majority of Linux systems at that point, and didn't have any hardware support for multiple streams. OSS with software mixing was a commercial product that wasn't upstream. ALSA had userspace mixing but it was very much not an out of the box experience, and didn't take advantage of hardware capabilities in the way Pulseaudio did to reduce wakeups and power consumption.
Even so, surely it would have been easier and better to just fix or replace dmix (in kernel, in the existing data path) than introduce a userspace daemon, break API compatibility, and so on.
It’s been 20 years and pulseaudio is still flaky / high latency / incomprehensible. Professional flows that care use stuff like jack.
TBH pipewire works much better than pulse, up to the point to replacing jack itself. But DMIX worked fine for non-professional user needs and with very low CPU usage. Yes, it was Jackd for the professional but Windows had ASIO drivers too.
Pipe might work better than pulse but it's still an overcomplicated mess compared to ALSA, which is itself an overcomplicated mess compared to OSS, which could have been easily made to support concurrent clients to /dev/dsp without all the API breakages and flaky deamons we had to suffer through.
Doing audio mixing well is something that is, for a number of reasons, hard to do in kernel. And if you're still using pulseaudio, why? The rest of the world's moved to pipewire, which also provides a jack-compatible interface.
PipeWire replaced Pulse like five years ago; who is using Pulse at this point to make statements like "20 years" meaningful? It isn't really an ongoing concern.
This is the era where I was the lead on Ubuntu laptop support, and I promise you that dmix was not a trivial option to make things work out of the box.
I always had some Knoppix live CD/DVD which had better defaults than Ubuntu itself on hardware autodetection and setup. I think they used kudzu from RH for a good while plus custom patches.
Bear in mind the Knoppix creator had a blind wife, up to the point to creating A.R.I.A.N.E, one of the best distros for the blind (and it was merged with main KNOPPIX, making the distro one of the best accesible ones out there). Thus, proper audio mixing was mandatory.
With the bundled installer you could install it to as a Debian Testing install in the spot. As I didn't have internet at home, I remember using Knoppix before Debian Sarge because it had a huge amount of things to play and test without worrying about odd hardware setups.
Some of the context here is that that at the time, Ubuntu was aiming to work on as close to 100% of existing PCs as possible to make it available to the largest number of users. Knoppix had a lot of great features and also was very opinionated, and that had an influence on the set of hardware it worked well on by default. I evaluated basically every decision made there in terms of whether Ubuntu should adopt the same ones, and there were several that were just not good choices in terms of supporting the widest set of hardware possible.
I’m genuinely confused. Why not buy an entry level kubota?
I guess the startup is selling low tech stuff in the 100-200hp range, but you start getting computers and stuff at that point with the conventional manufacturers?
They certainly sell sub 100 hp / $100K tractors that are reliable and low tech, so I’m struggling to see any differentiator except the engine size.
Also, half price is an odd claim. The Kubota M6 looks comparable to the $130K option from the startup, but starts at $100K.
I can’t read the article because cloudflare is blocking iOS now, apparently.
Also, for the small-medium range, a BEV or plugin / serial hybrid powertrain would be a game changer. Lots of low end weight, infinite torque at low speeds, and no hearing protection required to operate it. Also, it wouldn’t get as wicked hot in the summer for the operator, nor would it dump diesel exhaust everywhere.
A low tech version of that would be compelling (similar to slate).
Edit: they could even use standard mounts electrical for the generator and common battery packs, so if either powerplant blew up, it’d be a bolt-in replacement. The actual electric motors probably would never blow out.
You’re rounding down the Kibota price (starts at 109k) and mixing in Canadian $.. You get a cummins 12v with more power than an m6 (and bigger more capable chassis) for ~10k less than the kubota.
> Most artificial sweeteners have metabolic side effects, and lead to weight gain.
So does sugar. Everything ever credibly published on the effects of artificial sweeteners say four things:
1) everything else held equal, artificial sweeteners unequivocally reduce weight gain vs consuming equivalent sugar because sugar is 100% empty calories
2) some artificial sweeteners (e.g. sucralose) may increase appetite vs equivalent sugar, causing you to possibly eat more depending on which ones you consume
3) various artificial sweeteners may have non-weight-related negative effects on the body related to cardiovascular health, gut health, and so on
4) sugar definitely has a whole bunch of non-weight-related negative effects on the body related to cardiovascular health, gut health, and so on
Lumping simple sugar in with complex carbohydrates as equally beneficial because they're both carbohydrate molecules is horrendous prevarication. And bringing up "intense workouts" at all, which I'm sure you very well know is demographically an extreme outlier scenario, in a conversation about weight gain, is the most hilarious kind of derailment.
This just in, licorice kills dogs. Once in a while it kills people too. (affects insulin production, and aldosterone causing blood pressure effects then downstream effects on blood potassium and kidneys)
> However, given this study applied a heterogeneous ASB formula, it could not adequately consider the role of specific artificial sweeteners. Further research is needed to evaluate the potential effect of different artificial sweeteners and their doses on health.
>Most artificial sweeteners have metabolic side effects, and lead to weight gain.
I have not seen a single double blind study show this in the many decades low calorie sweeteners have been consumed (in normal amounts).
What I have seen is study after study showing the harms of consuming too many carbohydrates (the amounts contained in normal consumption of juice due to quantity of sugar).
There seems to be little to no evidence of any negative effects from just about any artificial sweeteners. I mean shoot, Aspartame immediately breaks down into some of the most common amino acids in the body. There's no biological mechanism for it to do anything negative.
Sugar, on the other hand, has very well known and studied health risks at the concentrations we see in a lot of modern 'staples' - soda and juice included.
BMW was one of the best for privacy the last time I checked.
reply