Filesystems are fine. The author needs to bone-up. I have several filesystems with in excess of 50 million inodes on them right now. We have a grok tree with over 100 million inodes in it. I'd post the DF outputs but slashdot's lameness filter won't let me.

To be fair, an old filesystem like UFS is creaky when it comes to directories, but modern filesystems have no problems with directories. And no filesystem has had issues with large files for ages (even UFS did a fairly decent job back in the day). BTRFS, EXT4, ZFS, HAMMER2 (my personal favorite since I wrote it), XFS (which is actually a very old filesystem that we used on SGI Challenge systems many years ago). It is just not a problem.

Generally these filesystems are using hashes, radix trees, or B-tree / B+tree style lookups for directories and inodes. H2, for example, uses a variable block-size radix tree, which means that a directory with only a few entries in it will be very shallow (even just all in one level if its small), despite the 64-bit filename hashes being evenly spread throughout the entire numerical space. But as the directories grow in size, the tables are collapsed into radix ranges and slowly become deeper. Indirect radix blocks are 64KB, so it doesn't take very many levels to cover a huge directory.

The only way one could do better (and only slightly better, to be perfectly frank), is to use some of the object-store features built directly into later NVMe chipset standards. Basically the idea there is that any SSD has an indirect block table anyway, why not just make it directly into a (key,data) object store at the SSD firmware level and then have filesystems use the keys directly instead of linear block numbers? Its totally doable, and not even very difficult given that most modern filesystems already use keys for directory, inode, and block indexing.

In anycase, the author needs to do some serious research and catch up to modern times.

-Matt

A few simple rules will make life easier.

#1 - Have two credit cards accounts. Put trusted services that would be annoying to re-enter on one (e.g. trusted online accounts such as Amazon, Apple), and make untrusted / ad-hoc, and over-the-counter purchases with the other.

#2 - Use Apple Pay or Google Pay instead of a physical card whenever possible. And in particular at gas stations. You can associate your 'secure' card account with your phone. Always use the phone-based nfc payment whenever possible.

#3 - Never make purchases with your debit card. Use the debit card for ATMs only, preferably inside locations or at banks.

#4 - If your bank's online account has the feature, have it text you the location and amount whenever your card is used.

That's it pretty much. Either my wife's or my card (usually my wife's) would get lifted maybe once year, but it was never an inconvenience because it was always the untrusted card, and almost always due to use at a gas station that did not have wireless payment at the gas pump.

These days of course we have chip cards, and even cards which don't print the credit card number on the front any more (but still print it on the back). Doesn't matter though because modern day thieves often don't lift cards via the magnet strip any more, they install cameras that take pictures of both sides of the card instead.

It is also possible to copy a chip card (actually not even all that hard because the extra information on the chip that isn't on the face of the card is often not actually checked by the CC company, so blank cards can be programmed fairly easily). And it is also possible to fake or break a chip reader at a merchant, causing the merchant to back-off to a slider or direct entry.

And regardless of that, if your CC number is stolen at all thieves will use it at locations which don't require chip cards. And even though your bank will back the charges out for you, you still have to go through the hassle of changing cards. Which is why you have two accounts... it removes that hassle. So chip cards, even secure ones, don't actually remove the hassle. Thus, take the steps above to minimize it instead.

-Matt

Firefox is still more cross-platform than chrome. Firefox will build on several of the BSDs, but not all of them. It will build on many other operating systems as well but they must have a rust compiler, unfortunately. Google won't take upstream patches for anything but the big 3... win/mac/linux. For some people, that is computing now but the reality is that Google is killing the little guy and they love it.

The number one complaint I get is about browsers. Can't upstream to Chromium. Too small for firefox. LLVM wants me to buy them servers to get upstreamed. That is a dependency for rust. What does this all mean? I have to spend 2 weeks port LLVM. A few weeks on rust. A few months on firefox. Meanwhile, I can get a new webkit building in a few hours. Mozilla needs to stop fighting open source and embrace it. Take the patches. Work with people. Be the exclusive browser in more places. Push it forward. Get momentum among tech oriented people again. People ask us what to use. We tell them what we use. It's that simple.

webkit exists. it's the basis for safari, gnome web (epiphany), and midori. We should be focusing on getting that up to snuff because it's the only thing that's tolerable to port to different platforms.

Firefox is a mess. it needs rust. It has thousands of ifdef os checks throughout the code. It's not thought out. It doesn't assume a default of a unix like os in many places which is much more common than anything else.

You can spend months porting firefox now. It used to take a few weeks. It's a nightmare to work with. They won't take upstream patches for smaller OS projects. That mean reporting over and over and over and over.

On platforms that firefox supports, it's actually not terrible aside from losing features over time. That's the most frustrating part. I think I'm two features away from being able to switch to firefox as my primary on some of the OSes I use.
1. Easier integration with yubikey. It does support it but it's a hassle whereas it just works in chrome.
2. CASTING. If i could cast content to a chromecast without using chrome it would be awesome.

This is also true for most languages in the last few decades. Look at PHP. it was break after break up through 7.x. 4.x to 5.x was really bad. Rust devs love to keep adding/modify and then expect everyone to do yearly upgrades. Go lang is the same way.

The biggest problem with the python upgrade from 2.x to 3.x is all the build software on top of 2.x. So many apps depend on python code to build including X.org, Gnome, Chrome and it's variants, etc. I just recently started deprecating large parts of python 2.x modules in my OS. Still issues with that too. So much software has to be removed from package repos due to this.

Luckily people are starting to wise up. Ninja is being rewritten in C now as samurai. Hoping many of the other tools are as well. Can't take the hit again with python 4.

Isn't that a feature in this case?

You don't actually know that. Right now IBM's strategy is to become RedHat to save it's cloud initiative after consulting alone failed. They used to push OS/2, Lotus and DB2. Lotus got sold. DB2 is dying. IBM morphs every decade or so into something new. RedHat will die, it's just when.

At best it will be Lotus Notes or OS/2, and live on with a small company somewhere after the fall.

By destroying trust, IBM has weakened the RedHat brand.

Take the hit and migrate to a free distro now. They can pull the plug at any time.

Sounds like we're going to continue to see select platform support with the financial backers listed. Too bad.

From a security perspective, rust is a good idea but it can't replace C if it can't run where C can.

Google already controls the web, no reason to go down to 2 engines instead of 3. Also, remember that apple and google can't get along at this. Google used to use webkit and forked blink because of it. It was the same engine previously!

Webkit is the most portable browser engine followed by firefox's engine. Killing webkit means killing browsers on some platforms entirely. Firefox is now limited to platforms and architectures that can run rust. Google refuses to take upstream patches for other operating systems.

Unifi gear does need a controller, but they have an ISP line (edgerouter, etc) that does not require a controller. It's the same hardware platform, but different software. Being able to login to one app and control all of your hardware is convenient and the unifi controller can run on linux, freebsd, windows or macOS in addition to a physical one. You can just spin up a VM for it if you want. The hardware device they sell can be powered over POE from the switch.

What CPU is in your desktop? I'm curious what that comparison is.

There are several factors in determining this. What is the OS used for? Why can't one upgrade more frequently?

If it's an embedded product, or an appliance, LTS releases make a lot of sense and really should support at least 4-5 years for many types of products to be viable. This is certainly true for IoT uses.

For servers, it's another story because we're in the era of spinning up new ec2 instances or using docker/kubernetees. If you do it right, it shouldn't be such a big deal to migrate to a newer OS beyond testing. Even so, ~3 years of support or more is ideal.

Desktop users can migrate more often for personal use, but in business environments you start getting into things like VPN and other security software. It's hard to control that and new versions are often not supported right away. If we're talking linux, the community has a break it and punt mentality on everything. It's hard to support many versions of software on linux. The latest pulseaudio hack or systemd damage and you're SOL. Next week they break dns resolving. So there's the enemy of the community mindset and security fighting each other.

When you start talking about mature operating systems, I think the sweet spot is around 4 years. Older than that and it's extremely difficult to support. For instance, there is no updated SSL library that is stable for 4 years. Look at the recent issue with FreeBSD patching 11.4. This isn't the project's fault, it's the pay to play mentality of that project. They don't want people hanging out on older releases very long so they dictate when everyone should update their OS.

For smaller projects, LTS isn't even a possibility because it cuts into the time to develop the software.

They don't have a house full of them, but you'd be surprised how many people have an echo or philips hue bulb.

Apple also hasn't released specs for getting it working natively instead of macOS with Linux. Running a VM isn't good enough. The most important point of all this is that when apple makes this m1 mac end of life, it will still have an OS that gets OS updates (Linux, *BSD, whatever)

First gen apple hardware gets killed fast.

It's also not just about Linux.