> what is cloudflare exactly?
Man-in-the-middle and gatekeeper of (large parts of) the web.
It's getting harder and harder to participate online without being subject to their surveillance and/or approval.
2,097 karma · joined April 22, 2018
Man-in-the-middle and gatekeeper of (large parts of) the web.
It's getting harder and harder to participate online without being subject to their surveillance and/or approval.
https://www.kegoutlet.com/prod_images/xlarge/2/0/SP202T-SS.a...
Thanks for the link. This gives me a direction worth investigating, at least.
Cheaper? I don't see how. We're filling from the same CO2 cylinders, and my total hardware cost was less than that of a midrange SodaStream without the adapter you describe.
More convenient? Maybe, depending on environment and use.
But mine has advantages, too: More fizz, no counter space required, fewer fragile plastic parts, standard components that are easily serviced/replaced, and the ability to carbonate liquids other than water without worry of backspray gumming up a countertop machine's internal components. (Your unit's instructions probably tell you to use only water, for this reason.)
> you can leave the larger tank shut off and away from living areas so that a leak doesn't pose a hazard.
I close my cylinder's main valve when it's not in use, and the two additional valves downstream of it (at the regulator and ball lock fitting) also work, so I think a leak is very unlikely. Even if there was one, I would expect it to be noticed quickly or else too slow for the released CO2 to cause harm.
That valve will attach to a standard female fitting, which you can put on the end of a hose coming from a pressure regulator, which will attach to a full-size CO2 cylinder available from a brewing or gas supply shop. CO2 refills are a lot cheaper this way.
Put cold water in the bottle with some extra space at the top. Squeeze out the air and attach the valve cap. Set the pressure regulator, connect it to the bottle, open the regulator's output valve, and watch the bottle that was slightly crushed by your squeezing expand back to its normal shape. Slosh the water around with pressure applied for maybe 10-30 seconds. Close the output valve and disconnect.
Voilà. Carbonated water.
IIRC, PETE soda bottles are pressurized to about 50 psi for retail shelves. I don't think they're likely to burst until well beyond 100 psi, and they'll deform before they burst, so if you're careful, you can go a little higher than 50 and make fizzier water than what you can buy in the store. I have used 70 psi many times.
Read up on precautions for handling pressurized gas before doing any of this. Wear eye protection. Don't turn your bottle or gas cylinder into an unguided missile. :)
Sadly, I don't have any info on microplastics released by this process. (Nor by countertop carbonators and their rigid plastic flasks.) I wish I knew of a suitable steel bottle to use instead.
When these DVCS appeared, Git's branch design departed from what "branch" meant practically everywhere else. That added to its already significant learning curve, creating more friction for people trying (or being asked) to adopt it.
Meanwhile, Mercurial's "branch" was closer to well-established norms. This was one of several factors that made it the easier of the two to learn, which was was important when already asking people to uproot from their familiar centralized systems and learn the ins and outs of distributed version control. I suspect it also made repository migrations more straightforward, avoiding the impedance mismatch presented by Git's branches.
You are mistaken here. Bazaar, Mercurial, and Git appeared at about the same time, and I think Bazaar was released first.
IIRC, Bazaar tried to distinguish itself by handling renames better than other version control systems. In practice, this turned out not to be very important to most people.
(Tangent: It wasn't clear at the time whether Mercurial or Git was the better pick. Their internal design was very similar. Mercurial offered a more pleasant user interface, superior cross-platform support, and a third advantage that I'm forgetting at the moment. Git had unbeatable author recognition. Eventually, Git's improved Windows support and the arrival of GitHub sealed its victory in the popularity contest. But all of that came to pass well after Bazaar was released.)
Even then, there's a good chance that web a API exists for the required hardware, so it still doesn't need to be an app.
No, not missing out. Just waiting a few weeks longer than I would on a rolling distro, until the improvements arrive in Debian Backports. (If I'm really impatient, I can install something manually or make my own backport, but I'm assuming most people won't do that.) I have experienced cases like you describe, such as when I bought an RDNA3 GPU shortly after the platform was released, but they have been infrequent in my experience, and never so urgent that I couldn't wait a few weeks.
> you don't need rock-solid stability on a gaming rig or even a "workstation," since uptime isn't really a consideration.
System uptime is a consideration whenever I need my computer for something immediately, but my choice of Debian is not only about that. It's also about my time. Debian generally requires attention less often than other distros. Less time spent troubleshooting when things break. Less time re-learning things or adjusting workflows when new software versions change their behavior or interface. Fewer annoying interruptions. A low-maintenance system leaves me more time to get work done, or play games.
Also worth noting: These days, a lot of the components that games use are provided by the likes of Steam or Flatpak, which means they will be at exactly the same version and updated exactly as often on every Linux distro.
You might want to enable Proton logging and have a look at what it says is going on.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
> Honestly, don't use debian for gaming, as it is too far behind. Gaming stuff needs a bit more bleeding edge packages.
Please stop spreading this misconception. There are only a tiny handful of packages that a Debian gamer might need to update, and those are generally available in Debian Backports. It's not what I would call a beginner distro for any purpose, but gaming on it is perfectly viable.
I'm having a good time in games, still getting other computing tasks done, and enjoying Debian's low-maintenance respect for my time. AMA.
It could also be lucky consequence of what games you play and what else you do with your computer.
I was a long-time Nvidia user, and had plenty of problems with their drivers. They ranged from minor annoyances when switching between virtual consoles (which some people never do) to total system freezes when playing a particular game (which some people never play). It would have been be easy for someone else to never encounter these problems.
Since switching to AMD a couple years ago, I have been much happier.
I wish the sample text included _underscores_, since I have occasionally found that they disappear with certain combinations of font + size + renderer.
And a run of all the numeric digits 0123456789, to show how their heights align.
And [square brackets], to show how easily they are distinguished from certain other glyphs.
And the vertical | bar, for the same reason.
...
Adobe Source Code Pro and Ubuntu Mono were my finalists. I think my preference would come down to window and font size, since Ubuntu Mono seemed to be narrower and leave more space between lines.
(Also, I kind of rushed the first few comparisons, so it's possible that I prematurely eliminated a typeface that I would have liked more.)
Agreed, and my comment was aimed at exactly that. :)
An example of my concern: What would happen to GPL-licensed software if the copyright expired quickly? Would that allow someone to include it in a proprietary product and (after the short copyright term ended) deny users the freedoms that the GPL is supposed to guarantee? I think those freedoms remain important for much longer than 10 years.
> (and no changes since remember, it's a constantly rolling window)
Do you mean that the copyright term countdown would reset whenever the author makes changes to their work? (I'm not sure if this is the case today.) If so, couldn't someone simply use an earlier version in their proprietary product in order to escape GPL obligations early?
> "if you're releasing under an open source license and thus giving up your standard first, second, and part of your third period of IP rights and monopoly, you're excluded from needing to pay a license fee because you've already enable the public to make derivative works for free for decades when they wouldn't otherwise anyway."
Yes, I think this makes sense. Thanks for sharing your thoughts.
Could this approach undermine the protections afforded by open-source licenses? (IANAL.)
It's best not to assume with these things. With my stock Debian Stable kernel, Proton says this:
fsync: up and running.
And when I disable fsync, it says this:
esync: up and running.
> But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both?
No, esync and fsync trade blows in performance. Here are some measurements taken by Kron4ek, who maintains somewhat widely used Wine/Proton builds:
https://web.archive.org/web/20250315200334/https://flightles...
https://web.archive.org/web/20250315200424/https://flightles...
https://web.archive.org/web/20250315200419/https://flightles...
> With vanilla being quite a bit behind esync?
Yes, vanilla Wine has historically fallen behind all of them, of course.
> Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.
We can agree on this. :)
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
It does, about a dozen times.
Are you perhaps referring to LGPL3? I think the license under discussion here is LGPL2.1.
https://github.com/chardet/chardet/blob/6.0.0/LICENSE
I'm not well versed in copyright case law, so I won't argue with the rest of what you wrote. Thanks for elaborating on your thoughts.
The library's test suite and interfaces were apparently used directly, not transformed. If either of those are considered part of the library's source code, as the license's wording seems to suggest, then I think output from their use could be considered a work based on the library as defined in the license.
I'm not following your logic there, and I don't see any mention of "transformative" in the license. Can you explain what you mean?
> He fed only the API and the test suite to Claude and asked it to reimplement the library from scratch.
From GPL2:
> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
Is a project's test suite not considered part of its source code? When I make modifications to a project, its test cases are very much a part of that process.
If the test suite is part of this library's source code, and Claude was fed the test suite or interface definition files, is the output not considered a work based on the library under the terms of LGPL 2.1?
Yes...
> and Anthropic fed the code to the tool,
Presumably, as part of the massive amount of open-source code that must have been fed in to train their model.
> so Blanchard didn't do anything wrong, and Anthropic didn't do anything wrong. Nothing to see here.
This is meant as irony, right?