Yay, another set of protocols that will just lead to more and more fragmentation.
You do acknowledge one issue with Wayland, probably the biggest issue with Wayland, but then fail to acknowledge the second biggest issue with Wayland being fragmentation.
I'm pretty sure everyone has settled by now, Personally I hate systemd. It's slow, relatively resource intensive, poorly designed in many aspects.
but as an init and service manager it's the best. Though I do have to say dinit does get pretty close for me now.
I personally use Arch on my desktop and artix on my laptop. I want Systemd to die just as much as the next Systemd hater, but unfortunately I don't believe we have anything better yet.
can't say I have experienced that. I use a myriad of modern but lower end systems and stuff like dinit still uses less resources and is in turn better for the speed and responsiveness of my systems
this is from the google research team, they contribute a LOT to many foss projects. Google is not a monolith, each team is made of often very different folk, who have very different goals
this is quite frankly, a really dumb picture that is wrong on many accounts
literally, all Chrome OS / chromium OS needs to do for me to actually embrace it. is native out of box flatpack support
one issue I might see them having with flatpack, is the permissions right now are handled kind of stupidly IMO. but if those get solved I think flatpack would be a great addition to chromium os ecosystem
Boring hit piece that way overblows some issues on the topic.
all chromeOS needs to be immensely more useful is flatpak support, if chrome OS supported flatpaks directly, it could very well be my goto (well not chromeOS directly, probably thoriumOS) for older linux PCs for general populace
sounds like a lot of work when you could just install arch or nobara and be done with it
uses the GNOME interface
yeah thats a no from me.
The reason why firefox and chrome work so well, is that they literally have been in development for over a decade. In Firefox's case, it's actually over two decades now.
Instead of trying to reinvent the wheel, why not support some currently existing alternative browsers that look promising? You have servo, you have webkit, and you even have a ladybird now. That's three potential browsers.
All three are under somewhat active development. Servo, in my opinion, looking the most promising, that shares a lot of dependencies with Firefox still, which means maintenance cost is not super high. It's easy to hack on, and of course it's rust. who doesnt love rust
this is a really dumb take lmao
Garbage post, it's clearly trying to get development centralized again as it should be, they point to the actively developed repo
the issue isn't federation or anything like that, the issue is finding a repo hosting service in a dmca resilient country
saying 'no code' from rivals seems highly misleading, and I can't seem to see a hard citation for this, in fact, it very directly contradicts this same sentence from the article
He also said that unlike SerenityOS, Ladybird will “leverage the greater OSS ecosystem,” meaning that it will use other open source libraries for some features.
it would be better to say they aren't relying on libraries and features from rivals. not that they will use "no code" from them, good code is good code afterall
that feeling when you can remeber what shade of orange emoji you used on your password
Trying to remain unbias, the super TLDR;
FDO decided that they didn't like vaxry's community and told him to fix or action will be taken against him (Banning from FDO) for violating their (FDO's)
Vaxry said, This is my community, It's not an FDO project, and is not under control of FDO, Doesn't fall under purview of FDO's COC, I will not be bullied. And posted the interaction.
FDO's COC committy didn't like that and banned vaxry from FDO.
Time for my personal bias Im not sure how I can hide this other then spoiler, but ignore it if you don't want my very bias opinion;
::: spoiler spoiler FDO for sure over stepped their bounds. FDO did wrongfully invoke their COC against hyprland's community, Their COC is extremely clear on it's "scope" https://www.freedesktop.org/wiki/CodeOfConduct/ under which hyprland absolutely doesn't fall under. That being said, OFC FDO retains the right to ban anyone from their services as they please (I'll explain why this is extremely bad below). But they invoked the COC which is extremely important here.
Vaxry absolutely acted unprofessionally in publicizing this, on the other hand, I'm really glad he did because it's insane that FDO is attacking the hyprland community in the first place, which is an extremely self isolating community. It's very much "what happens in the discord is a discord thing". Outside of the discord, hyprland community is perfectly fine. I've not seen a single "Hyprland fan" go around shitting on anything else (granted this is hard to judge since you need to be given context of someone shitting on something, to be a hyprland fan), on the contary, I have seen many people publically shittying on vaxry on multiple forums.
FDO was in their right to ban Vaxry for publicizing the emails, but I don't think it was a good idea at all. They essentially punished Vaxry for airing their dirty laundry. Proving him right in the end. It's important to note, that given context, Drew's articles on Vaxry are insanely biased against him, with the intent to drum up hate towards vaxry (going so far as to imply Vaxry would call people the N-Word when giving support to people by using extremely misleading and cherry picked context)
The original emails are best explained by vaxry himself so check out his blog.
In the end, Vaxry acted unprofessionally and got banned for it, but FDO acted equally unprofessionally, and their actions greatly overstepped the rights they had (as far as enforcing COC goes, their original email)
Now WHY is FDO banning vaxry so important? Pretty much everything that matters in terms of linux gui development is on FDO's services. Wayland protocol discussion, Mesa, Wlroots etc. by banning vaxry from these services, he is pretty much no longer able to directly interact with the wayland community. (At least not without ban evasion or someone else acting as a proxy)
EDIT: I forgot my conclusions.
I strongly feel like FDO is using their position as the people who control linux to push their politics unto others. Hence Vaxry's original blog post How Freedesktop/RedHat harass other projects into submission
:::
oh boy here we go I strongly disagree with this article
While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.
.tar ARE messy, sometimes they don't work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO
Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.
Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don't appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.
see above
Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged "Windows workflow" (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.
Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME...
This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don't have updater services, as package managers are way better at doing that.
I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.
This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn't need that, or to have no updates at all.
Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?
Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn't that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.
Appimages don't even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.
I'd argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a "curated" service. So we can grant one here.
There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages... you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn't break.
This is how you get malware.
the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.
They are not well maintained
There is a well known "bug" on modern Ubuntu, where Appimages lost their "works on every Linux Distro", because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.
An application format, that is incompatible with the latest version of its core dependency, is broken.
This is a very minor issue, i've had way more issues with traditional repo packages then I have had with appimages.
Lack of Sandboxing ...
I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.
Random location ...
Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren't "one of the major standards" this is just wrong. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Duplicated libraries
Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don't share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.
This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.
and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.
Appimages are not needed Flatpak solved many Linux desktop issues at once ...
None of these provide reasons as to why appimages aren't needed. Appimages still offer a lot, for one I can just download and run it I don't need to worry about installing and uninstalling application when I just want to try it, I don't need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.
Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don't want to support, Users don't need to download a stupid appstore or use CLI (not a single appstore i've used to date isn't hot garbage, I hope cosmic-store will be different).
I agree with a lot of the points LTT had, I was pretty excited for this video when I saw it. But the response was just complaing and excuses instead of just being nice and simple "here's the issue you had, We can either fix it, or can't for these reasons..."
Literally never heard of it let alone know anyone who cares...
Yeah, can't say I really care about this, this seems like a bit of a nothing burger.
I never do the latter anymore. was downloading a pretty rare dvd rip awhile ago I only found after a really long time. download was slow, for about 4 days I was downloading and then seeder went offline and afaik never came back up. now I try to make sure if im the only seed to try and make sure they get priority to decrease the chances of that happening
EDIT: btw props to btdigg, I did eventually find it in some collection thanks to that
OOB experience matters a LOT.
right? gotta wonder why it was even posted in the first place
Note that in oars git repo itself a lot of tags were removed because of idiots calling it "problematic" https://github.com/hughsie/oars/commit/bbb10186cbecb49252610e5604ed025df8f4c8b7
the actual gitrepo explained why it's neccessary, not wanted
* `sex-homosexuality`: As of 2020,
[various countries](https://www.humandignitytrust.org/lgbt-the-law/map-of-criminalisation/)
have laws which criminalise lesbian, gay, bisexual or transgender (LGBT)
people. In order for software and content to be distributed in those
countries without breaking the law, and possible reprisal, it is necessary to
be able to tag software and content which contains LGBT references, so that
it can be hidden in those countries.
However, in other countries (for example, the EU), discrimination laws
explicitly prohibit discrimination on the basis of gender or sexuality. So
while LGBT tagging may be available in OARS data, consumers of that data must
only apply it in countries where the law requires that.
Love his content, he is quite entertaining, even when just doing a cooking video, has some good takes and some bad takes but who doesnt at this point.
Keep in mind that other reputable repos like izzyondroid still work, fdroid is more then one thing. We wont loose the apps, nor the 3rd party repos, the only thing really "at risk" here is the official fdroid repos.
this isn't like some closed source stuff, the entire fdroid ecosystem is fully foss so anyone can sweep in at any time and do their own thing while still being mostly or completely compatible
for me it's been a lot better, I currently run arch without any issues (other then wine but thats because I never bothered to config it right when I setup bottles)
Ldac is not actually that good, it's actually fairly rare that LDAC beats out something like SBC XQ let alone AAC
EDIT: for elaboration, LDAC works at 3 main data rate ranges 990/909, 660/606 and 330/303. Ldac is only high res at the 990 range, and even at that range, it still often looses when pipewire is compiled against libfdk. keep in mind that it's hard to get real numbers on LDAC because decoding is proprietary, meaning I had to disassemble headphones and connect those for verification, but typically AAC on supported headphones beat out 990kbps LDAC (which is hilarious btw considering LDAC can rarely actually work at 990kbps anyways) and both SBC-XQ and LC3Plus (both of which are usable with pipewire) regularly beat 660kbps LDAC.
TLDR LDAC is crap and SBC-XQ is typically more accurate and lower latency, and LC3Plus is even better then that. and if you have AAC compatible headphones assuming latency isnt a major issue (which you are using LDAC so it's not) just use AAC, both fidelity and latency is better
EDIT: I should mention, it is known that vendors will tune codecs, I believe Valdikks article in habr briefly goes over this. so it's very possible that tuning could mean that x codec, including LDAC could be the only good codec, however with how badly LDAC maintains 990kbps, I doubt it will make much of a difference
I hate that I just read the words " back in the day" in the context of chromebooks. this feels too new for me xD
color management is actually super hard to do, so making sure it's done right is very important, so this is one of the few times it actually makes sense. I mean, just take a look at windows, it still looks like shit over there.
this is a wayland issue. Due to how wayland works, it cannot drop messages, this means if the messages stop being accepted (IE. the program becomes very slow and not very responsive) the application will wind up dying. EEVDF helped resolve a lot of these issues. but they arent gone yet.
a fairly easy replication cause is to start a large rust project compile since cargo will thread to oblivion if it gets the chance, then use the PC on wayland. Applications can frequently die, Firefox, MPV, Kate, gnome web, chromium, games, etc. it also doesn't matter what compositor you use right now as gnome, kde sway all share the issue
EEVDF really does help stop a lot of these crashing though
not sure how relevant these may or may not be, but there are some client device implementations
EDIT: paste didnt work https://github.com/openairplay/open-airplay
matroska for media, we already have MKA for audio and MKV for video. An image container would be good too.
mp4 is more prone to data loss and slower to parse, while also being less flexible, despite this it seems to be a sort of pseudo standard.
(MP4, M4A, HEIF formats like heic, avif)
you probably have face/iris unlock enabled, I dont have that phone specifically, but some phones will use the screen to make sure there is enough light for the sensor to work
EDIT: I thin it might just be face unlock
I disagree, making your own packages is nice, but it's not like it's needed. I know multiple people who don't touch the AUR or custom pkgbuilds at all
I find that fair, but at the same time, proton has a rocksolid history at this point. OFC they will likely add their features to it, and maybe remove some. But im the end its still open source and under gpl licence, so its not like proton cam change that unless they remove all other commits.
Because Wayland is STILL lacking a lot of things that people need.
those arent even the same thing
I have a 12vdc direct power USBC charger for my tablet. This will totally fry any normal USBC device it touches.