I’ve only ever used Outlook when forced to by an employer and I find it a dreadful application to use. I would guess that most people prefer something else. I would imagine that most people tend to stick with the default email app on their computer (no idea what that is on Windows as I’ve managed to avoid having to use Windows for 7 years now).
The default mail app on Windows is now called Outlook for Windows, no relation to the Outlook in Office (sorry, Microsoft 365 Copilot), and it's a significantly worse barely functional webview. It also replaced the entire Calendar app, which was decent.
In the US, social security is based on the 35 highest paying years. If that system is good enough for social security, I don't see why we don't do the same for government pensions.
Only tangentially related: Is there some joke/meme I'm not aware of? The github comment thread is flooded with identical comments like "Thanks, that helped!", "Thanks for the tip!", and "This was the answer I was looking for."
Since they all seem positive, it doesn't seem like an attack but I thought the general etiquette for github issues was to use the emoji reactions to show support so the comment thread only contains substantive comments.
> It also seems that attacker is trying to stifle the discussion by spamming this with hundreds of comments. I recommend talking on hackernews if that might be the case.
Totally agree with the author of rg here. Config names should be unambiguous. Anyway, must have been something else, then. As I've said, I cannot remember what was the specific problem, only that it wasn't quite compatible with the workflow I was used to, and now it'd take another full-in attempt to switch to figure out what was so annoying to me back then.
To be fair, GCC's design was motivated by the same thing as the license. They intentionally didn't modularize GCC so that it couldn't be used by non-free code.
> Anything that makes it easier to use GCC back ends without GCC front ends--or simply brings GCC a big step closer to a form that would make such usage easy--would endanger our leverage for causing new front ends to be free.
> Why does there seem to be much more market for NAS than for direct attached external HDD?
I can access my NAS from anywhere in the world, but you can only access your direct-attached drives when sitting at your desk.
I can hide my NAS in a closet, but your direct attach drives are wasting valuable desk space and causing noise in your workspace.
My NAS has a software raid (raidz2) so any two of my drives could die without losing a single bit of data. Technically this is possible with direct attached drives too, but usually people aren't attaching multiple external drives to their computer at the same time.
Multiple people/computers/phones can access my NAS simultaneously, but your direct attach drives are only usable by a single computer at a time.
I can use my NAS from any device/operating system without worrying about filesystem compatibility. With direct attach drives, you need to pick a filesystem that will be supported by the devices you want to plug in to it.
The downside is a NAS is running 24/7 which will consume more electricity than drives you only plug in on-demand, and file transfers will be slower over a network than directly plugged in to your computer, but 99% of the time the speed difference does not matter to me. (It really only impacts me when doing full-disk backup/restore since I'd be transferring hundreds of gigabytes.)
You can configure a NAS to use Wake-on-LAN, so that it will not run 24/7, but only when you wake it up remotely. After you finish using it, you power it down remotely, until the next use.
No one is giving their IoT devices public IPv4 addresses. They would be behind a NAT. RFC 1918 provides 17,891,322 usable IP addresses for each private network. If we want to be a little more adventurous, RFC 6598 provides an additional 4,194,302 usable addresses and 240.0.0.0/4 is another 268,435,454 usable addresses "reserved for future use" since 1989, but still sitting unused so we can use them as internal addresses inside a NAT anyway (for example, AWS uses this range internally).
Show me a network that is using all 290,521,078 addresses and I'll show you a network managed by a team of network engineers who can just set up IPv6.
You still have to manage those and assign them through DHCP every time the device wakes up and turns the radio on. Maybe WiFi 7 will address that with the low power mode? Also, I don't want a 100 sensor mesh network on my LAN. That's why Thread uses a IPv6 6LoWPAN. One should use that if they want to bridge to IP.
I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].
On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.
Could you be more specific on how to circumvent the android permission model + sandbox? So far I have only thought of two ways an XZ-like backdoor could circumvent that:
1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.
2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.
The defining aspect of the XZ backdoor was that it was baked into the OS itself, being linked into memory space by about half of the system and activated by being packaged in a specific way in a specific distribution. If you wanted to ignore 1), you would have to choose a different example.
If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.
reply