Ehh, Microsoft only opened exFAT after smartphones dropped all SD card slots and it was no longer possible for them to extort Android device manufacturers with patent licensing.
Last I checked, only at the high end and Google devices, and substantially less true in non-US markets.
Careful with proclaiming such a bubble to be universal. I am sure in mountain view some PMs make decisions based on "oh but we killed the SD card years ago" but they don't have actual power to do that.
It's fun to see bubble-driven remarks like "no phones have SD card slots anymore" or "there are no headphone jacks on phones nowadays".
Welp, you can influence that and I won't buy a phone without either.
Or a phone with a removable battery. I am personally disappointed by that one. A lot of phones are skimping on internal batteries these days and it kills the life of the phone fairly quickly.
The previous phone I had, since I had been burned repeatedly by phones I was otherwise happy with but the internal battery didn't last a year, I decided to shop around for the few remaining Android phones with decent performance that had an easily replaceable battery. I had to pick a model from late 2016.
Personally, I don't have a problem if the battery isn't easily removable. I don't think I'll find myself in the situation of needing to hot-swap batteries on the move before I get home, today's battery technology has ensured sufficient energy density to make all-day long battery life a reality.
What I ask of manufacturers is that at least the battery isn't glued or soldered in, and that there are clear instructions on how to unscrew the back of my phone to replace the battery after it starts dying out. That, and make it easy to take off the back (no adhesives (looks at you apple), and no taking out the front screen to access the battery), and make it easy to buy a genuine battery from the manufacturer's website.
I think that's a good compromise of thinness, ease of manufacture and ease of replacability.
> today's battery technology has ensured sufficient energy density to make all-day long battery life a reality.
That is a sad comment.
Yesterday's battery technology ensured sufficient energy density to make _all-week_ long battery life a reality. Yes, those were much weaker phones computationally, but I'm fine with staying with just phone calls, SMS and calendar when I'm low on battery, for an extra week...
In some aspects, smartphones have become toys. Scrolling through reddit/facebook/twitter doesn't really make it worth having a smartphone, since those are all dumb activities.
However there are certain features that a smartphone gives which I wouldn't give up. Navigation with google maps, being able to do banking services on the go with my bank's app, being able to review flashcards with the Anki app, having my railcard/tesco clubcard/nectar card on my phone and never losing it, being able to check any important emails, checking the news if something breaking happens and I need to know instantly.
Heck, we praise Apple for bringing services like calling an ambulance for you if your pulse shows a certain pattern matching a heart attack (via the apple watch), and we also praise smartphones for actions like alerting people for emergencies like a terrorist attack or issuing weather warnings. I wouldn't give up any of those features just to have a dumb nokia phone with a week-long battery life.
Why give them up? Have 75% of the battery life be used for all of those activities, but build the phone so you could still make calls and send text messages for a longer while later.
Also - Smartwatches are silly IMHO; and people can be alerted just fine with a voice or text message.
It's more the ubiquitous and uncontrollable fast-charging that kills batteries. I would love for charging power controls baked into Android, as I know there are one or two manufacturers who have them (ASUS and Sony?).
I agree. It's a token gesture. Even if you do have SD card slots android offers to extends storage to that, which I think means it formats the card as EXT4 or something.
Maybe TV manufacturers care about this, but in mobile it's a non-event.
Maybe Microsoft could open-source MSDOS in order for FreeDOS to have a rejuvenating moment.
Yes, they like to do these kind of things in the name of loving open source nowadays. Also open sourced a 40 year old BASIC implementation which can only be good for a Computer Museum display.
~2009 + 20 years. You've got a long time to wait if you're not part of OIN.
They're arguably invalid patents, in the sense that the filesystems concepts within are not remotely novel and the application to FAT is trivial and obvious.
In a sense, it doesn't matter if the patents are valid or not, but isn't the rule that you have to apply within one year of making the invention available, and shouldn't including it in a release count for that?
(Maybe that rule changed with the big changes around first to file and expiration based on application instead of grant date.)
No, you are correct. Publicly shipping the product that implements the invention starts the clock. But here, the parents claim priority to an application filed in 2004. (That means the invention was disclosed in that earlier application, even if it wasn’t specifically claimed.) When you claim priority like that, your 20 years starts running from the earliest priority date. So the patents expire in 2024.
That's not accurate. The initial implementation (in Linux 5.4) was also a derivative of Samsung exFAT code, however, it was not contributed by Samsung directly and it was based on a much older version. Samsung then suggested¹ it would be better to upstream their latest exFAT driver (sdfat), which is what has happened now - after improving the code to be suitable for mainline.
Not sure if this answers your question, but if it really bothers you, you could change the CSS rules that your browser applies to a specific site. If you are using firefox, the file to edit is `chrome/userContent.css`.
I know it doesn't help others, but in my experience people using such software actually like this retro look (and I agree it does have some appeal to it - function before form).
I think my issue is more with navigation than style. Like Seeing the whole thread tree inline would be nicer no, even for the folks who still want the plain text feel?
There was Gmane. Too bad nothing had replaced it. It was the de facto site used when sharing links to mail list posts and it did have thread navigation that made sense.
Finally, we get a non-journaled semi-cross-platform filesystem. fat32 just wasn't cutting it... /s
When will we get a proper performant journaled cross platform filesystem that doesn't require additional software on Windows, MacOS, and Linux? I can't believe we still don't have anything like that.
Journal is about obviating fsck, just do journal replay to make the fs consistent again. I think for most media like USB sticks, the most platform interoperable file system is UDF. The gotcha that trips most people up I think, is that you shouldn't partition the media device. Just format the whole block device as UDF. I do this with mkuddf using defaults and it works fine across all three operating systems with similar performance as FAT32.
The file format is very simple. The write guarantees of the file system for full OS usage may not be simple, certainly they're not simple on Linux, and Btrfs development shows that this is hard.
The GRUB Btrfs driver is pretty small considering the Btrfs feature set. And yet it understands all the multiple device stuff, the logical and physical device abstraction, and snapshots and subvolume navigation.
I like always on checksums for every block, both metadata and data. It's a good fit for the cheaper flash media out there including USB sticks which non-deterministically report back garbage, rather than a discrete read error.
It's not about that - the filesystem needs to be simple snough that multiple vendors' implementations will be compatible.
Remember SOAP interoperability? Me neither. It was too complex for its own good. That's why REST is used everywhere today and experienced web developers smile every now and then when they remember they don't need to use it anymore. Well, most of them at least...
I’m not talking about complexity to use but rather architectural complexity. Rather than being a simple fs driver, it (in the ZFS model) consumes raw devices then re-exposes them as software-defined volumes optionally with a file system api already exposed or as software defined block devices that can then be formatted with another filesystem.
It basically upends the entire separation of layers and requires a completely different approach to use.
Btrfs actually has a simpler interface than ZFS: it consumes block devices and exposes only a filesystem, not more block devices. It does have integrated volume management functionality, but overall acts much more like a "regular" filesystem than ZFS.
>Finally, we get a non-journaled semi-cross-platform filesystem. fat32 just wasn't cutting it... /s
Hope you never had to store files larger than 4GB otherwise FAT32 would not work for you. (Before you respond with "that's what archive files / files splitting are for", not every device that takes files on an SD card and supports FAT32 has a way to join files on the fly/a way to read archived files.)
Only sort of. Windows communicates with WSL via 9p, which has decent performance but is still a network protocol. It certainly isn't possible to mount an ext4 filesystem on D: with native performance.
It's a business investment, nothing more. There was a recent story about how M$ treats open-source devs (AppGet vs WinGet). If they could EEE Linux, they'd do it.
For those of us who lived through the "Linux is cancer" days, we are truly living in interesting times :-)