Hacker Newsnew | past | comments | ask | show | jobs | submit | argsnd's commentslogin

What a meaningless statement. If information can influence elections it can change who is in power. This isn’t possible in China.

It can still influence what those people do, and the rules you have up live under. In particular, Covid restrictions in China were brought down because everyone was fed up with them. They didn't have to have an election to collectively decide on that, despite the government saying you must still social distance et Al, for safety reasons.

I disagree. Elections do not offer systemic change. They offer a rotation of administrators. While rhetoric varies, the institutions, strategic priorities, and coercive capacities persist, and every viable candidate ends up defending them.

Presumably every pixel is 32 bits rather than just 8. So the count starts at 33.2MB just for the display.

It is now, but back then it was 1 byte, with typical resolutions being 800x600. There were high-color modes but for a period it was rare to have good enough hardware for it.

I have run x11 in 16-color and 256-color mode, but it was not fun. The palette would get swapped when changing windows, which was quite disorienting. Hardware that could do 16-bit color was common by the late 90s.

Fun thing - SGI specifically used 256 color mode a lot, to reduce memory usage even if you used 24bit outputs. So long as you used defaults of their Motif fork, everything you didn't specifically request to use more colors would use 256 color visuals which then were composited in hardware.

Much better to stick to 1 bit per pixel. :-)

Like in Sun SPARCStation ELC. No confusing colors or shades.


1bpp (at low resolution) is still relevant today on epaper screens, though some of them now allow for shades of grey or even color.

Most aren't all that low res either... 300dpi is standard.

But what if it's a UTF8 bit? Then it'd be 2 bits.

Which proves time travel exists, all those "two bits" references in old Westerns.


Damn pixel bit-depth bloat!

Since MV3 Chrome has not had better extension API support, although Apple’s insistence on publishing them on the App Store means availability is still restricted. I’ve found that using `xcrun safari-web-extension-converter` on almost any Chrome extension works fine and I’ve self-signed a few (eg. Bypass Paywalls Clean) with Xcode to run on my Mac and iPhone.


> Apple’s insistence on publishing them on the App Store means availability is still restricted.

This is not true. You can distribute Safari extensions outside the Mac App Store.

While it's true that you can't distribute Safari extensions outside the iOS App Store, mobile Chrome doesn't even have extension support, so in this case, Safari has vastly better extension support.


You do still need to notarise it with an Apple Developer membership, right? Else you have to enable unsigned extensions every time you open Safari. The cost barrier is still there even if the approval barrier isn’t.


Yes, but your initial comment was kind of a strange way to phrase a cost complaint. After all, Google insists that extensions be published in the Chrome Web Store, and that requires Google's approval, a process that can often take much longer than App Store approval.

I suspect that the difference in extension availability is mostly due to desktop market share, since Safari is nonexistent on Windows and Linux.


There’s quite a difference between a one time $5 fee and an annual $99 fee for the economics of publishing a free browser extension.

Given almost 100% compatibility with the same Web Extension APIs that Chrome uses, I think you’d expect near-parity in extension availability between Chrome and Safari if that barrier didn’t exist.


> There’s quite a difference between a one time $5 fee and an annual $99 fee for the economics of publishing a free browser extension.

Yes? I didn't deny that. I said your initial comment didn't mention cost.

> Given almost 100% compatibility with the same Web Extension APIs that Chrome uses, I think you’d expect near-parity in extension availability between Chrome and Safari if that barrier didn’t exist.

It feels like you ignored the points I made in my last comment. Why would you expect near parity in extension availability when you can't even develop Safari extensions on Windows and Linux computers?


“publishing them on the App Store” was intended as (perhaps imprecise for you) shorthand for all of these distribution issues.

You very much can develop Safari extensions on Windows or Linux because they use largely the same APIs as Chrome extensions as I already mentioned. Any differences are well documented. The only thing you need a Mac for is, again, distribution. If not for that it’s really not that different to developing a website that will open on Safari without access to an Apple device.

Once upon a time Apple had a separate Safari extensions website where they allowed extension developers to publish or sign extensions after registering for free as they recognised these barriers. They could either be distributed on Apple’s extensions gallery or you could distribute the files yourself.


> Any differences are well documented.

LOL, I wish.

I would note that I'm a professional browser extension developer and have a great deal of experience with this.

> The only thing you need a Mac for is, again, distribution.

Or, you know, testing your software. Or are you in the habit of shipping software without any testing?

> If not for that it’s really not that different to developing a website that will open on Safari without access to an Apple device.

Also a bad idea.

> They could either be distributed on Apple’s extensions gallery or you could distribute the files yourself.

You may have still have needed Safari to package the extension, though I don't recall for sure, because that was 15 years ago.

In any case, I'm glad you mentioned it, because there was not near-parity in extension availability back then either.


You can load unpublished extensions with developer mode. It's not as convenient but works just fine. Try that with Safari.


API level maybe, but what I care about is being able to install an extension with one click and no hassle. Apple makes this too hard to extort money via the App Store, so they can shove it where the sun doesn't shine.


I think the subscriptions tend to be a significant discount over paying for tokens yourself


Presumably it has to be “no” instead of “0”


I find that Fedora hits the right balance of stability while being up to date for anything desktop and specifically gaming focused, Debian has different priorities and packages can be a bit too old. And it’s less of a faff than Arch.


You are comparing Fedora with Debian stable. Everyone who wants to have Debian stability (and ecosystem) with the most new upstream software should go for Debian Testing (and don't be fooled by the name "testing" !). Debian Stable is for servers, Debian Testing is for desktops. Just try Debian Testing (and I used Slack, Red Hat, Ubuntu, Debian)


This is from like 20 years ago, but I remember Debian Testing as the one where updates broke the system most frequently, or maybe the longest without fixes: Stable was stable, Sid / unstable was what most Debian developers were using... and Testing was the weird thing that was neither a release nor tested and fixed "live" by developers.

What changed?


Most of the problems that break a system are being resolved in unstable rather than testing.

I've ran testing on my home server, though since it's a bit old now I've switched it over to stable when testing switched to stable.


This is how the flow happens: [upstream] -> [Debian Sid] -> [Debian Testing] -> [Debian stable]

The testing happens in Debian Sid.


But who actually tests Testing? If it's not the Debian developers themselves, fixes could take a while. I seem to recall Testing breaking because of package version combinations that never existed, so were never tested, in Sid.


The same question applies to any other distribution (Fedora, Arch, etc): who tests them ?


Debian testing is pretty much the worst option to choose. It can be as "unstable" as unstable, while being nearly as out-dated as a stable at points.

If you want to help Debian test the next release and actually report issues choose Debian testing.


The "testing" name is one of the worst decision of Debian community IMHO. It misleads people.


I very much agree with this, it also scared me off Debian Testing initially as well.

I wonder how many potential users have been scared off by the name... Maybe Debian devs like it that way, less annoying desktop users to support.


It looks like you have never used Debian testing (or used it 10 years ago ?). The testing phase is in Debian Sid and _not_ in Debian testing.


Archlinux can be a pretty good choice for gaming. Not necessarily because of anything Archlinux does: most distros can do anything, if you configure them.

No, just because the Steamdeck's distro is built on Arch, and so you can piggyback on what they are doing.


Arch is really in a sense the absence of a distro, but keeping a package manager with up to date packages. No bloat bundled, just install exactly what you want.

I don't see why 'piggyback on what [Steam deck is] doing' wouldn't work just as well on any distro, you'd just have a load of extra stuff you're not using too.

That's nothing against Arch, it's what I use, I'm just saying really the only magic is in doing less.


> Arch is really in a sense the absence of a distro, but keeping a package manager with up to date packages. No bloat bundled, just install exactly what you want.

You might be right in terms of a desktop environment. But Arch does have its own opinions, eg it picks systemd by default. And it gives you a default kernel that has a few patches applied and a config picked for you.

> I don't see why 'piggyback on what [Steam deck is] doing' wouldn't work just as well on any distro, you'd just have a load of extra stuff you're not using too.

Yes, that was in my original comment. However setting up all the configs take a bit of time, and with Arch you can just literally copy large parts of the config files from the Steam deck.

One advantage that Arch has over many distros: as a rolling distributions it's usually easier to get up-to-date packages, you mostly get them by default.


Eh, aside from GPU drivers -- which I download directly from nvidia anyway -- I don't feel like gaming is much affected by the distro packages being a couple years old. We pretty much just run Steam, Discord, and Chrome on these things, and those all have their own update schedule independent of the distro.


I'm hopeful that's been fixed by now, but when I switched to Linux a year ago I started with Debian, and had a lot of issues with input latency for games on Wayland. Switched to Fedora which was two KDE versions ahead and never had that issue again.


Because you used Debian stable (which is mostly for servers). Try Debian Testing. And don't get fooled by its name "testing" - it is because Debian community reserved "stable" for Debian stable. Debian testing is also stable :-)


You're right because the games run in containers anyway, steam-runtime.


In what way do you think this is meaningfully occurring? I ask because I have not heard of Chrome or Firefox being inhibited on energy efficiency by platform limitations.


79 out of 100 documents Mistral OCR 3 provides better output than Mistral OCR 2.


This seems to be correct from about 5 minutes of research.


this is a genuinely awful description of Irish history


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: