That's not app-specific behavior. That's how the Windows library loader works.
That's not app-specific behavior. That's how the Windows library loader works.
I'm aware of the Windows DLL load behavior, and how it creates "DLL Hell." I never thought of the security implications, because I assumed that Windows behaved more
The root of the problem is that the affected applications are installers, which need to be run with elevated rights. On Linux systems, for example, when an application is run with escalated rights (through SUID or sudo), the dynamic library loader uses only the system library paths and ignores user specified paths (such as the LD_LIBRARY_PATH environment variable).
Why the HELL doesn't Windows do the same for apps run as administrator?
I'd second "use the thunderbird archive" and add "use IMAP."
Thunderbird can archive mail into a single folder, or per-year folders, or per-month folders. When you are using IMAP, those folders are on the server, and accessible from any client. All of the clients I'm aware of allow you to "subscribe" or not to folders of your choosing, and most offer more fine grained control to choose what to download and keep locally in order to control client storage and bandwidth use.
Thunderbird has an excellent search engine built in, so searching is straightforward.
Thunderbird also supports IMAP tags (labels), so you can apply an arbitrary number of tags/labels to each message. This is a lot more flexible than sorting messages into folders manually. Once you start tagging messages, a clear and simple workflow becomes clear:
Your inbox should contain only messages that require you to act on them in some way. Once a message no longer requires action, tag it if necessary and archive it. Or, if it is definitely not required, delete it.
Simple. Now your inbox is cleaner, you'll spend less time sorting mail, and a lot less time searching for it. You can unsubscribe from older archives if you like, or simply choose not to keep them locally to save disk space on the client.
Did you watch the video, or are you one of the "80%" who didn't?
You don't need practice to lightly tap a lock on its side for 5-10 seconds. There's no technique to practice. It's light tension and tapping.
One of the issues if that if you need a high-resolution measurement of the real time that has passed between one event and another, it simply isn't available under POSIX systems. For scientific purposes, that sucks.
If you're on a PC, that's still a virtual terminal, emulating a terminal.
As I recall, Square Enix released a complete collection of Final Fantasy, but only with Japanese language. I'd love to see the same thing translated into English.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
Neither of those things are true, which is a bad place to start your argument. It shows that you don't understand systemd, at all.
systemd added a command in which to start a new shell instance, using the same shell as before, while creating a new environment for it. It did not add a new shell.
systemd is also building new network configuration client components, not server components. If they can do a better job than NetworkManager, it'll replace that project. Right now, it hasn't.
Binary log files (PUKE)
The old logs are still available. The new ones allow administrators to check the status of a process and view logs and stdout/stderr from that process. This is a significant improvement.
Extremely poor documentation
systemd has some of the best, or at least the most complete documentation among any system component I can name.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
Ask an administrator rather than an end user. Or ask a developer. If you're getting "my system boots faster" as an answer, then you're clearly asking the wrong people.
Systemd has very good documentation, unit files are very clear and concise, it actually makes use of Linux features which were not widely used beforehand (cgroups). There are lots of reasons to believe that systemd is good software.
"No replacement for displacement" trades meaning for rhyme
No, it doesn't. In the context of engines, "no replacement for displacement" and "no substitute for cubic inches" are equally meaningful. At least to Americans. To everyone else, the latter sacrifices BOTH meaning and rhyme.
Really, that's the big one. When a gearhead says, "There's no replacement for displacement," it conveys exactly the kind of macho attitude that you'd expect from someone who revels in big engines. The statement "there's no substitute for cubic inches" does not. It doesn't just lack rhyme or finesse, it lacks attitude and meaning.
"there no substitute for cubic inches" About 7,850 results
"no replacement for displacement" About 266,000 results
C is an excellent system programming language and nothing else has managed to supersede it. All major operating systems are written in C, including Linux, the BSD/MacOS kernel and the Windows kernel.
Both the XNU kernel (OS X and iOS) and Windows kernel are written, in part, in C++. A subset of C++, in both cases, to be fair, but C++ all the same.
Actually, that clarifies that the zram feature did not make it to the Linux kernel until 2014, meaning that OSX had it prior to Linux.
zswap, which is similar to the OS X feature, was merged into the Linux kernel mainline in kernel version 3.11, released on September 2, 2013. OS X 10.9 "Mavericks" was released on October 22, 2013.
But compressed memory isn't new. It's old tech, and quibbling about which of the many implementations was released first is silly as it ignores decades of such products.
What you want is zram, not zswap.
Not according to the documentation.
[Zswap] takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool.
That document is several years old now.
Oh, so it's not enabled by default in my distro?
It appears to be enabled currently in both Ubuntu, Fedora, and RHEL and CentOS.
Oh, great, it's experimental.
It was marked experimental in 2013. In the context of a discussion about a feature that hasn't even been introduced in Windows, it's fair to note that Linux developers have been working on such a feature, and made it generally available several years earlier.
Wonderful! If I turn it on, it may suddenly turn itself off when I get a kernel update for 14.04.
It was disabled in Ubuntu while they tried to diagnose instability in a PPC kernel. The feature was not related to the instability.
If you don't like Ubuntu's method of kernel maintenance, by all means, use a different distribution. However, the practices of one company should not be considered a defect in *Linux*.
Saying you have something when it's experimental, not enabled by default, enables and disables with updates, and not easily available to the vast majority of your users is silly.
It would be, perhaps, but you have all of your facts wrong.
but osx being exploitable if you have console/local access? that's not really news.
I don't know why so many people don't get this.
The bug doesn't require a human at the console. Any code-execution bug can be escalated to root access because of this bug. It is not, by itself, a remote root, but security vulnerabilities can be combined, and a combination of bugs typically rates at the highest threat level of any individual element of the combined attack.
That is, imagine that you have a bug in your browser that causes it to automatically open PDF files in an external viewer. This rates as a minor security threat. You also have a PDF reader that allows code execution, but code executes as the user, with limited rights, so this rates as a moderate security threat. You also have a dynamic linker that allows any process that can call system() to write to protected files. This is a critical security vulnerability.
An attacker can now infect a server that you visit, or maybe convince you to visit a server that they control, and combine those to get root access on your system.
10.0 times 0.1 is hardly ever 1.0.