I think you missed the simple fact that everything was working fine before, without cramming everything in the init process.
Has everything been crammed into the init process? In what may have been a bad PR move, the systemd people use "systemd" both to refer to the init process and to their whole suite of daemons, most of which run as processes separate from process 1, so "systemd does XXX" doesn't necessarily mean "XXX has been crammed into the init process".
Except when it doesn't and since it swallows stderr
A sane background/daemon process launcher sends stdout and stderr somewhere where it gets logged. Are you saying systemd just sends the standard output and error of stuff it launches to/dev/null, or that it sends them somewhere that's not easy to process? (Launchd sends them to the Apple System Log mechanism, which, yes, does have a binary log database, but ASL also sends stuff, including the stdout/stderr from launchd-launched processes, to the Boring Old Text File/var/log/system.log.)
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance.
Not that systemd affects POSIX compliance (and not that Linux is certified as POSIX-compliant; I haven't found it to be significantly worse than any other UN*X in terms of "annoyingly different from everybody else" - frankly, if there isn't at least one thing your UN*X-family OS does annoyingly differently from all the other UN*X-family OSes, it can't really call itself a UN*X:-)).
Reminds me of the movie fight club where the guy supposedly worked for a car company, and part of his job was working with formulas to determine if the cost of lawsuits from deaths would be higher than the recall cost.
At least according to a Mother Jones story from 1977, something similar did happen at Ford, although it wasn't based on lawsuit costs, it was based on a National Highway Traffic Safety Administration figure for the dollar value of a human life.
The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period... but it's not exact.
That's the reason we adjust for leap years. The reason we adjust for leap seconds is that the speed of the earth's rotation 1) isn't exactly 360 degrees in 86400 SI seconds and 2) changes over time, so it's not even a fixed value close to 360 degrees in 86400 SI seconds.
So the project is named after the one and only JavaScript file in the project? And its relationship to JavaScript is similar to the relationship between a program with an embedded Lua interpreter and Lua?
Meaning "node.js requires some C++ bindings and there are only versions of those bindings for V8" (or "can only be versions of those bindings for V8", as they're dependent on the way V8 works)? (I.e., better phrased as "the only JS engine on which node.js can run is V8".)
Unfortunately, too many designers use tiny light gray type. CONTROL + and CONTROL - don't help much when the contrast is that low, and some designs don't expand enough to be easily readable.
If someone were to develop glasses that reduces one's ability to handle low-contrast text, it would be wonderful if all UI designers (including, but not limited to, Web designers) were forced to wear them while doing design work (and if any marketing and management types who interfered with the usability of the resulting designs were put to death immediately).
The link has nothing to do with what the parent implied or did not imply... did he mean "user root" or root less as in X-Windows integration into the Mac OS X GUI?
Both actually has nothing to do with the topic... so my bet is the parent only was shuffling words;
The question was asked because the only way a trojan will be able to modify the files protected by System Integrity Protection would be if it could 1) turn System Integrity Protection off or otherwise disable it or 2) somehow evade its protections.
As that page says, "The Client was coded in Java to support as many OS as possible. It requires the Java Version 7 and is extremely persistent.", although it "supports less features" on OS X, Linux, and other "Unix machines".
Presumably it runs as root if it "You can view, create, delete, rename, download, copy and move all files & folders on your clients machine.", unless the ability to do that to all files and folders is one of those features not supported on UN*Xes. (Can you turn off rootless mode on OS X 10.11 with this tool?)
Perhaps "OmniRAT Lets Hackers Control Android Phones, Windows, Mac, and Linux PCs" really means "OmniRAT Lets Hackers Control Android Phones *from* Windows, Mac, and Linux PCs". A screen grab in the Avast blog post speaks of a "Multi-OS Server - Android Client", which may mean that the server that controls the remote phone can run on Windows, OS X, and Linux.
I thought there was a Unicode code point shortage?
Nope. Originally, Unicode only had room for 65536 code points, but it was extended with Unicode 2.0 to 1,112,064 code points. At least if the Wikipedia page on it is to be believed, only 120,737 characters have been defined as of Unicode 8.0.
Maybe that's just because UTF-8 because has to maintain backward compatibility with ASCII.
Nope, UTF-8 can actually represent even more code points than that, but any encoding that results in a code point value past 0x10FFFF is invalid in UTF-8.
From what I understand, in doing so, it wastes a few hundred other code pages.
Nope. All that "maintaining backward compatibility with ASCII" involves is "encoding code points 0x000000 through 0x00007F as a single octet equal to the code point, and not using those octets in the encoding of any other code point"; the encoding scheme can represent everything up to 0x7FFFFFFF, i.e. it only loses the uppermost 2,147,483,648 code points, and can still handle the lower 2,147,483,648 code points. That's a lot more than the Unicode limitation of 1,112,064 code points.
(It was better when it was just the International Earth Rotation Service and it was clearer from the name that adjusting the earth's rotation was their job.)
Of course the title is misleading! For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries (for example, synchronization).
Unless you're one of the user-space programmers writing the compiler or the system libraries.:-)
The programmers at Undo are programmers like that, not typical user-space programmers writing code for which the ISA doesn't matter.
(And a fair bit of kernel programming is done with the ISA hidden by the compiler and lower-level kernel code, for that matter.)
It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel",
You're thinking of the third item in their list.
The first item in their list does have to do with ARM; its register set is different, and OS APIs for debugging have platform dependencies - in particular, the Linux kernel handled A64 differently from A32 - and those particular developers happen to be using ptrace() and had to handle A64 differently.
The second item in their list has to do with the C library doing more atomic load/store operations on A64 for some reason; they speculate that it's "to better support multiprocessor systems."
The problem here is that the article had a misleading title; it was "ARM64 vs ARM32 -- What's different for Linux programmers" when it should have been "ARM64 vs ARM32 -- What's different for people working at a company whose core technology is a record and replay engine, which works by recording all non-deterministic input to a program and uses just-in-time compilation (JIT) to keep track of the program state". What Undo Software are doing is rather specialized and system-softwareish, and they run into issues that wouldn't affect the majority of programmers; those are the issues they're talking about.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.
There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".
The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
The "UN*X"/"Un*x" convention was created by other members of the community (I remember it being used in USENET postings), and it's the one I use.
If you think The Hurd is Unix, then so is QNX, right?
I don't think the Hurd is a trademark UNIX or a derived-from-Bell-Labs-code UNIX. I do, however, consider it Unix-like enough to consider it a UN*X, and consider QNX at least somewhat Unix-like, although it appears that there's a lower-level API below the POSIX API that can be used.
Slashdot Mirror
I think you missed the simple fact that everything was working fine before, without cramming everything in the init process.
Has everything been crammed into the init process? In what may have been a bad PR move, the systemd people use "systemd" both to refer to the init process and to their whole suite of daemons, most of which run as processes separate from process 1, so "systemd does XXX" doesn't necessarily mean "XXX has been crammed into the init process".
Except when it doesn't and since it swallows stderr
A sane background/daemon process launcher sends stdout and stderr somewhere where it gets logged. Are you saying systemd just sends the standard output and error of stuff it launches to /dev/null, or that it sends them somewhere that's not easy to process? (Launchd sends them to the Apple System Log mechanism, which, yes, does have a binary log database, but ASL also sends stuff, including the stdout/stderr from launchd-launched processes, to the Boring Old Text File /var/log/system.log.)
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance.
Not that systemd affects POSIX compliance (and not that Linux is certified as POSIX-compliant; I haven't found it to be significantly worse than any other UN*X in terms of "annoyingly different from everybody else" - frankly, if there isn't at least one thing your UN*X-family OS does annoyingly differently from all the other UN*X-family OSes, it can't really call itself a UN*X :-)).
Reminds me of the movie fight club where the guy supposedly worked for a car company, and part of his job was working with formulas to determine if the cost of lawsuits from deaths would be higher than the recall cost.
At least according to a Mother Jones story from 1977, something similar did happen at Ford, although it wasn't based on lawsuit costs, it was based on a National Highway Traffic Safety Administration figure for the dollar value of a human life.
The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period ... but it's not exact.
That's the reason we adjust for leap years. The reason we adjust for leap seconds is that the speed of the earth's rotation 1) isn't exactly 360 degrees in 86400 SI seconds and 2) changes over time, so it's not even a fixed value close to 360 degrees in 86400 SI seconds.
So the project is named after the one and only JavaScript file in the project? And its relationship to JavaScript is similar to the relationship between a program with an embedded Lua interpreter and Lua?
Node's JS engine *is* V8.
Meaning "node.js requires some C++ bindings and there are only versions of those bindings for V8" (or "can only be versions of those bindings for V8", as they're dependent on the way V8 works)? (I.e., better phrased as "the only JS engine on which node.js can run is V8".)
node and chrome have nothing to do with each other besides sharing the JS engine.
node.js uses a JavaScript engine, as it's written in JavaScript. Chrome is a browser that has a JavaScript engine. So they share even less than that.
So the question is "does running node.js on V8 render it vulnerable?"
You mean like sunglasses? Or if you really want to reduce the contrast a ton, a welder's mask.
Anything to keep idiots from thinking that, for example, grey on black is appropriate for text that anybody would actually read.
Unfortunately, too many designers use tiny light gray type. CONTROL + and CONTROL - don't help much when the contrast is that low, and some designs don't expand enough to be easily readable.
If someone were to develop glasses that reduces one's ability to handle low-contrast text, it would be wonderful if all UI designers (including, but not limited to, Web designers) were forced to wear them while doing design work (and if any marketing and management types who interfered with the usability of the resulting designs were put to death immediately).
Do you think that the King cares about that? The car was on "the King's Road", or perhaps "the royal road".
No, Phil probably doesn't care all that much. (Then again, it stopped being the King's road, except by name, back in 1821.)
I don't think anyone can be said to come "from Syriza".
I'd say that Alexis Tsipras did.
The link has nothing to do with what the parent implied or did not imply ... did he mean "user root" or root less as in X-Windows integration into the Mac OS X GUI?
Both actually has nothing to do with the topic ... so my bet is the parent only was shuffling words ;
If by "the parent" you mean the comment where I asked "Can you turn off rootless mode on OS X 10.11 with this tool?", then I can assure you with 100% certainty that he meant "the System Integrity Protection feature of OS X El Capitan, often referred to as "rootless mode", as he is me. The "root" in there refers to the user root; "rootless" mode disables even the root account from making some changes.
The question was asked because the only way a trojan will be able to modify the files protected by System Integrity Protection would be if it could 1) turn System Integrity Protection off or otherwise disable it or 2) somehow evade its protections.
"Can you turn off rootless mode on OS X 10.11 with this tool?)" What is "rootless mode" supposed to be?
Another name used for the mode where System Integrity Protection is enabled.
It appears that both the server and client are multi-platform, possibly as Java packages.
https://www.linkedin.com/pulse...
As that page says, "The Client was coded in Java to support as many OS as possible. It requires the Java Version 7 and is extremely persistent.", although it "supports less features" on OS X, Linux, and other "Unix machines".
Presumably it runs as root if it "You can view, create, delete, rename, download, copy and move all files & folders on your clients machine.", unless the ability to do that to all files and folders is one of those features not supported on UN*Xes. (Can you turn off rootless mode on OS X 10.11 with this tool?)
In which part of the linked articles do they talk about Macs ?? Didn't find it.
Or about Windows or Linux, for that matter. I suspect they mean that the server that controls the infected phone can run on Windows, OS X, or Linux, not that the infecting client runs on Windows, OS X, or Linux.
Perhaps "OmniRAT Lets Hackers Control Android Phones, Windows, Mac, and Linux PCs" really means "OmniRAT Lets Hackers Control Android Phones *from* Windows, Mac, and Linux PCs". A screen grab in the Avast blog post speaks of a "Multi-OS Server - Android Client", which may mean that the server that controls the remote phone can run on Windows, OS X, and Linux.
I thought there was a Unicode code point shortage?
Nope. Originally, Unicode only had room for 65536 code points, but it was extended with Unicode 2.0 to 1,112,064 code points. At least if the Wikipedia page on it is to be believed, only 120,737 characters have been defined as of Unicode 8.0.
Maybe that's just because UTF-8 because has to maintain backward compatibility with ASCII.
Nope, UTF-8 can actually represent even more code points than that, but any encoding that results in a code point value past 0x10FFFF is invalid in UTF-8.
From what I understand, in doing so, it wastes a few hundred other code pages.
Nope. All that "maintaining backward compatibility with ASCII" involves is "encoding code points 0x000000 through 0x00007F as a single octet equal to the code point, and not using those octets in the encoding of any other code point"; the encoding scheme can represent everything up to 0x7FFFFFFF, i.e. it only loses the uppermost 2,147,483,648 code points, and can still handle the lower 2,147,483,648 code points. That's a lot more than the Unicode limitation of 1,112,064 code points.
Perhaps most importantly, Unicode 8.0 support now enables the crucial U1F32D character.
Hot dog!
They might have some people with ideas about how to grab blueberries at high speed.
Because farmers are strange people that own guns, buy seeds from Monsanto,
Some do, some don't.
Do the farmers who supplied you with the straw you used to build that strawman do so?
Naturally: the earth's rotation must be sped back up to match the clocks.
Time for the International Earth Rotation and Reference Systems Service to get to work on providing that service, then....
(It was better when it was just the International Earth Rotation Service and it was clearer from the name that adjusting the earth's rotation was their job.)
Of course the title is misleading! For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries (for example, synchronization).
Unless you're one of the user-space programmers writing the compiler or the system libraries. :-)
The programmers at Undo are programmers like that, not typical user-space programmers writing code for which the ISA doesn't matter.
(And a fair bit of kernel programming is done with the ISA hidden by the compiler and lower-level kernel code, for that matter.)
It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel",
You're thinking of the third item in their list.
The first item in their list does have to do with ARM; its register set is different, and OS APIs for debugging have platform dependencies - in particular, the Linux kernel handled A64 differently from A32 - and those particular developers happen to be using ptrace() and had to handle A64 differently.
The second item in their list has to do with the C library doing more atomic load/store operations on A64 for some reason; they speculate that it's "to better support multiprocessor systems."
The problem here is that the article had a misleading title; it was "ARM64 vs ARM32 -- What's different for Linux programmers" when it should have been "ARM64 vs ARM32 -- What's different for people working at a company whose core technology is a record and replay engine, which works by recording all non-deterministic input to a program and uses just-in-time compilation (JIT) to keep track of the program state". What Undo Software are doing is rather specialized and system-softwareish, and they run into issues that wouldn't affect the majority of programmers; those are the issues they're talking about.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.
There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".
The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
The convention was created by the people who created it. Eric Raymond claims that Dennis Ritchie says the all-caps version stems from being "intoxicated" by the ability to produce small caps with troff and the new typesetter, and that Ritchie later tried to get the spelling changed to "Unix" in some Bell Labs papers, but failed.
The "UN*X"/"Un*x" convention was created by other members of the community (I remember it being used in USENET postings), and it's the one I use.
If you think The Hurd is Unix, then so is QNX, right?
I don't think the Hurd is a trademark UNIX or a derived-from-Bell-Labs-code UNIX. I do, however, consider it Unix-like enough to consider it a UN*X, and consider QNX at least somewhat Unix-like, although it appears that there's a lower-level API below the POSIX API that can be used.