Islam is opposed to the separation of church and state.
Eh, and so is Christianity generally. So much so that we do not even have separation of church and state in Denmark: the Church of Denmark is the official state church, which is written into the Constitution. There is freedom of conscience and worship, but one religion (Lutheran Protestant Christianity) is officially established, while the others are (according to the Constitution) merely tolerated, allowed to worship as they wish "provided that nothing at variance with good morals or public order shall be taught or done" (section 67).
Of course, in practice the church has lost almost all of its power in a gradual reform process spanning the past few decades. But I don't see this as some bit fundamental disagreement between Christianity and Islam, more a practical issue of which parts of each religion are dominant and what kinds of political power they have. In the current era, the temporal power of Christian theocrats is waning, so they are no longer much of a practical threat. But not because Christianity is doctrinally particularly great. Christian conservatives simply lost the political battle; if some things had turned out differently, they might have won, or at least come to more of a stalemate. But they didn't.
Is it really a large number? Here in Scandinavia as far as I can tell there are indeed Muslim extremists, but a quite small number. I work with a number of Muslims in a regular office job, and they are more or less normal people. More religious than the average Scandinavian, but then so are Americans.
And in terms of actual crimes committed, there doesn't seem to be a whole lot of terrorism going on here. There have actually been many more people killed by anti-Muslim nativists (like Anders Breivik) than by Muslim terrorists. Meaning that the people trying to "save" us from the Muslims are killing more of us than the Muslims are. In which case I would like to request that they stop trying to "save" us...
The biggest problems are more run-of-the-mill socioeconomic problems. A large number of young people in poor suburbs of Copenhagen and Aarhus end up committing petty crimes or joining street gangs. These are disproportionately immigrants, although it applies to Danes in those areas as well (who join biker gangs, which for some reason in Denmark are very white, and heavily involved in smuggling).
That tends to be too restricted for things to actually run, alas. For example, something in a chroot can't even see libc or use standard Unix utilities on its own files, because/lib and/bin are outside of the chroot. You end up having to install a whole second copy of Linux inside the chroot...
Does show a longstanding problem with the Unix security model, though: nothing more fine-grained than per-user permissions. There's no reason Steam should be able to delete (or even read) anything in my home directory other than its own files, but the only real way to keep it from doing so using straight Unix permissions is to create a new local user for every application.
I don't think it's really accurate to say the BSDs are primarily source-based from a user perspective these days. FreeBSD, NetBSD, and OpenBSD all use binary packages. You can build from source, but that's true on Debian too. The various BSD and Linux distributions differ a bit mainly in how strongly encouraged each option is, e.g. OpenBSD strongly recommends installing the official binary packages, not building your own.
Considering it's the third major Unix to try fixing this problem, I don't think the problem is nonexistent or invented. Solaris came up with SMF, and OSX came up with launchd, basically to fix the same problem, which is that tangles of shell scripts are unmaintainable, buggy shit.
If you take the "mining" metaphor seriously, alternately you could advise commodity hedging, like what oil companies do to manage the risk of drilling (drilling costs $ but returns bbl of oil). Though there isn't really much practical difference between the two metaphors, I'll admit.
And what you say about mainframe stability vs other HW - I don't think this is entirely true.
If you mean just individual servers, I agree, regular HW isn't too bad, and doesn't take a ton of admin power. I was thinking more of the case of replacing a big mainframe with a cluster, which has a whole different kind of administrative overhead. You can generally assume that a mainframe stays internally connected and working: CPU cards don't randomly lose connections to each other, your database and application software don't have to deal with networking hiccups or node failures, etc. Whereas if you move that to a cluster architecture, even using some kind of orchestration layer like OpenStack, you can't really assume that everything will "just work". Instead it has to be architected and administered as a distributed system, which needs quite a bit of effort on both the development and operations sides.
Thanks, that's an interesting comment. Especially with x86 servers getting fairly big these days (the 80-core, 4TB-ram monsters you mention), I can see that being plausible for some scenarios. Are all the services you ran previously each able to fit in a single x86 server now? If so that sounds like it'd greatly ease migration. One of the big pain-points of migration from mainframes to x86 clusters has traditionally been that it's hugely expensive to re-architect complex software so that it will run (and run reliably) on a distributed system, if it was originally written to run on a single system. But if the biggest single service you run is small enough to fit in your biggest x86 box, then you don't have to do the distributed-system rewrite.
The IBM pricing really is quite high (there are a ton of licensing fees for the hardware, maintenance, and software). But the systems work reliably. You get a giant system that can run a whole lot of VMs, with fast and reliable interconnects, transparent hardware failover (e.g. CPUs inside most mainframes come in redundant pairs), etc. To get a similar setup on commodity hardware you need some kind of "cloud" orchestration environment, like OpenStack, which can deal with VM management and migration, network storage, communication topology, etc. The advantage of an x86-64/OpenStack cluster solution is that the hardware+licensing costs are loads cheaper, and you don't have IBM levels of vendor lockin. The disadvantage is that it doesn't really work reliably; you're not going to get 5 9s of uptime on any significantly sized OpenStack deployment, and it will require an army of devops people to babysit it. The application complexity also tends to be higher, because failures are handled at the application level rather than at the system level: all your services need to be able to deal with non-transparent failover, split-brain scenarios, etc. Also the I/O interconnects between parts of the system (even if you're on 10GigE) are much worse than mainframe interconnects.
Putting it in pid1 is mostly driven by cgroups (the Linux kernel's hierarchical process-grouping/resource-management system). The initial kernel design for cgroups was that it was a shared resources managed via a pseudofilesystem (cgroupfs), but the developers of that subsystem seem to have decided that design was unworkable, and are moving towards a design where there can be exactly one userspace controller of the cgroups system at any given time. That more or less has to also be the process supervisor, or else you can't really do sensible things with tying resource-management to services (and increasingly, containers). And that all has to happen when the system is brought up, too. So either it needs to be in PID1, or it needs to be in several PIDs that are tightly coupled via an IPC mechanism. The systemd designers consider the second design more complex and error-prone. See e.g. here, plus a third-party comment here.
It's a process supervisor / service management system. Booting the machine isn't really the most difficult job of such a system, just the special case of starting some things on boot. More of the work goes into the non-boot case, and at the moment a lot of interest is in container-based virtualization. The kernel cgroups system provides the basic primitives for building such systems: hierarchical process groups, resource limits, etc., but you need a userspace layer to make it usable, e.g. managing creation/destruction of containers (and their associated networking, resources, etc.). Systemd is the userspace layer.
There are fairly similar approaches in other Unixes, though with pros and cons. Solaris uses SMF, and OSX uses launchd, both of which replaced more old-school shell-script-based systems for similar reasons. FreeBSD has toyed on and off with porting launchd from OSX, but the porting effort stalled. For the moment it relies on a more "DIY" solution where it's up to the sysadmin to maintain a tangle of shells scripts plugging things together, e.g. integrating jail management with resource constraints (RCTL), services, and networking. All the pieces are there, but either you write your own shell scripts to glue them together, or you can use something like cbsd. That has some pros and cons as well.
This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems. In all likelihood anyone with a user account on a North Korean computer is pretty heavily monitored, and ensuring nobody violates policy can be enforced by "other means" than Unix permissions.
In this case it appears to actually be a firm hired by the porn company in question. The complaint was sent by Takedown Piracy LLC, which is one of those fly-by-night operations that sends out mass incompetently drafted DMCA requests on behalf of clients (it's important not to do any competent lawyering, because that would reduce the profit margin). In this case they were hired by a company called Adam & Eve (NSFW, obviously) and sent the letters on that company's behalf.
In theory submitting a false DMCA request is illegal. And there are theoretically plausible civil suits as well, if someone submits a false or reckless DMCA request that damages your business. But has anyone in history actually suffered any repercussions from submitting false DMCA requests? It seems people submit false ones all the time, and not only borderline mistakes but things ranging from reckless disregard for the truth to outright maliciously false requests (e.g. for SEO purposes). Yet I have never heard of anyone being prosecuted or sued for it.
You could call it that, sure, but in practice many people studying the possibility of life on other planets refer to their specialty as "astrobiology". For example, the University of Washington has an astrobiology program.
Some are less sci-fi than others though. An astrobiologist studying the possibility of life on Mars at least has some pretty concrete work they can do: there is new data coming in, there are experiments that can be performed with probes to confirm or rule out some theories, etc. An astrobiologist studying the possibility of star-eating lifeforms in deep space has... less concrete work to do.
Yeah, the FCC has a bit of a garbage-in, garbage-out problem with the whole complaint system. The proportion of knowledgeable complaints about things like signal interference or fraudulent business practices is pretty low. Lots more people use the FCC complaint system to file a complaint about curse words or a flash of a breast on network TV.
It looks like a judgment was actually entered for $80m, so saying that you got an $80m judgment is accurate. Now whether you can collect on that judgment is another story. It's possible that they should have informed shareholders of the low likelihood of the judgment being paid, via an SEC filing.
Slashdot Mirror
Islam is opposed to the separation of church and state.
Eh, and so is Christianity generally. So much so that we do not even have separation of church and state in Denmark: the Church of Denmark is the official state church, which is written into the Constitution. There is freedom of conscience and worship, but one religion (Lutheran Protestant Christianity) is officially established, while the others are (according to the Constitution) merely tolerated, allowed to worship as they wish "provided that nothing at variance with good morals or public order shall be taught or done" (section 67).
Of course, in practice the church has lost almost all of its power in a gradual reform process spanning the past few decades. But I don't see this as some bit fundamental disagreement between Christianity and Islam, more a practical issue of which parts of each religion are dominant and what kinds of political power they have. In the current era, the temporal power of Christian theocrats is waning, so they are no longer much of a practical threat. But not because Christianity is doctrinally particularly great. Christian conservatives simply lost the political battle; if some things had turned out differently, they might have won, or at least come to more of a stalemate. But they didn't.
Is it really a large number? Here in Scandinavia as far as I can tell there are indeed Muslim extremists, but a quite small number. I work with a number of Muslims in a regular office job, and they are more or less normal people. More religious than the average Scandinavian, but then so are Americans.
And in terms of actual crimes committed, there doesn't seem to be a whole lot of terrorism going on here. There have actually been many more people killed by anti-Muslim nativists (like Anders Breivik) than by Muslim terrorists. Meaning that the people trying to "save" us from the Muslims are killing more of us than the Muslims are. In which case I would like to request that they stop trying to "save" us...
The biggest problems are more run-of-the-mill socioeconomic problems. A large number of young people in poor suburbs of Copenhagen and Aarhus end up committing petty crimes or joining street gangs. These are disproportionately immigrants, although it applies to Danes in those areas as well (who join biker gangs, which for some reason in Denmark are very white, and heavily involved in smuggling).
Most Italians do not descend from the ancient Italic tribes.
You're not going to draw me into a Slashdot thread on this subject. Ok, sure, I posted this one comment in the thread. But no more.
That tends to be too restricted for things to actually run, alas. For example, something in a chroot can't even see libc or use standard Unix utilities on its own files, because /lib and /bin are outside of the chroot. You end up having to install a whole second copy of Linux inside the chroot...
Does show a longstanding problem with the Unix security model, though: nothing more fine-grained than per-user permissions. There's no reason Steam should be able to delete (or even read) anything in my home directory other than its own files, but the only real way to keep it from doing so using straight Unix permissions is to create a new local user for every application.
I don't think it's really accurate to say the BSDs are primarily source-based from a user perspective these days. FreeBSD, NetBSD, and OpenBSD all use binary packages. You can build from source, but that's true on Debian too. The various BSD and Linux distributions differ a bit mainly in how strongly encouraged each option is, e.g. OpenBSD strongly recommends installing the official binary packages, not building your own.
Considering it's the third major Unix to try fixing this problem, I don't think the problem is nonexistent or invented. Solaris came up with SMF, and OSX came up with launchd, basically to fix the same problem, which is that tangles of shell scripts are unmaintainable, buggy shit.
If you take the "mining" metaphor seriously, alternately you could advise commodity hedging, like what oil companies do to manage the risk of drilling (drilling costs $ but returns bbl of oil). Though there isn't really much practical difference between the two metaphors, I'll admit.
And what you say about mainframe stability vs other HW - I don't think this is entirely true.
If you mean just individual servers, I agree, regular HW isn't too bad, and doesn't take a ton of admin power. I was thinking more of the case of replacing a big mainframe with a cluster, which has a whole different kind of administrative overhead. You can generally assume that a mainframe stays internally connected and working: CPU cards don't randomly lose connections to each other, your database and application software don't have to deal with networking hiccups or node failures, etc. Whereas if you move that to a cluster architecture, even using some kind of orchestration layer like OpenStack, you can't really assume that everything will "just work". Instead it has to be architected and administered as a distributed system, which needs quite a bit of effort on both the development and operations sides.
Thanks, that's an interesting comment. Especially with x86 servers getting fairly big these days (the 80-core, 4TB-ram monsters you mention), I can see that being plausible for some scenarios. Are all the services you ran previously each able to fit in a single x86 server now? If so that sounds like it'd greatly ease migration. One of the big pain-points of migration from mainframes to x86 clusters has traditionally been that it's hugely expensive to re-architect complex software so that it will run (and run reliably) on a distributed system, if it was originally written to run on a single system. But if the biggest single service you run is small enough to fit in your biggest x86 box, then you don't have to do the distributed-system rewrite.
The IBM pricing really is quite high (there are a ton of licensing fees for the hardware, maintenance, and software). But the systems work reliably. You get a giant system that can run a whole lot of VMs, with fast and reliable interconnects, transparent hardware failover (e.g. CPUs inside most mainframes come in redundant pairs), etc. To get a similar setup on commodity hardware you need some kind of "cloud" orchestration environment, like OpenStack, which can deal with VM management and migration, network storage, communication topology, etc. The advantage of an x86-64/OpenStack cluster solution is that the hardware+licensing costs are loads cheaper, and you don't have IBM levels of vendor lockin. The disadvantage is that it doesn't really work reliably; you're not going to get 5 9s of uptime on any significantly sized OpenStack deployment, and it will require an army of devops people to babysit it. The application complexity also tends to be higher, because failures are handled at the application level rather than at the system level: all your services need to be able to deal with non-transparent failover, split-brain scenarios, etc. Also the I/O interconnects between parts of the system (even if you're on 10GigE) are much worse than mainframe interconnects.
Putting it in pid1 is mostly driven by cgroups (the Linux kernel's hierarchical process-grouping/resource-management system). The initial kernel design for cgroups was that it was a shared resources managed via a pseudofilesystem (cgroupfs), but the developers of that subsystem seem to have decided that design was unworkable, and are moving towards a design where there can be exactly one userspace controller of the cgroups system at any given time. That more or less has to also be the process supervisor, or else you can't really do sensible things with tying resource-management to services (and increasingly, containers). And that all has to happen when the system is brought up, too. So either it needs to be in PID1, or it needs to be in several PIDs that are tightly coupled via an IPC mechanism. The systemd designers consider the second design more complex and error-prone. See e.g. here, plus a third-party comment here.
It's a process supervisor / service management system. Booting the machine isn't really the most difficult job of such a system, just the special case of starting some things on boot. More of the work goes into the non-boot case, and at the moment a lot of interest is in container-based virtualization. The kernel cgroups system provides the basic primitives for building such systems: hierarchical process groups, resource limits, etc., but you need a userspace layer to make it usable, e.g. managing creation/destruction of containers (and their associated networking, resources, etc.). Systemd is the userspace layer.
There are fairly similar approaches in other Unixes, though with pros and cons. Solaris uses SMF, and OSX uses launchd, both of which replaced more old-school shell-script-based systems for similar reasons. FreeBSD has toyed on and off with porting launchd from OSX, but the porting effort stalled. For the moment it relies on a more "DIY" solution where it's up to the sysadmin to maintain a tangle of shells scripts plugging things together, e.g. integrating jail management with resource constraints (RCTL), services, and networking. All the pieces are there, but either you write your own shell scripts to glue them together, or you can use something like cbsd. That has some pros and cons as well.
You might be surprised to find that FreeBSD's jails have their own network-virtualization features too.
This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems. In all likelihood anyone with a user account on a North Korean computer is pretty heavily monitored, and ensuring nobody violates policy can be enforced by "other means" than Unix permissions.
That isn't the case in other countries with free college education (i.e. most of Europe).
In this case it appears to actually be a firm hired by the porn company in question. The complaint was sent by Takedown Piracy LLC, which is one of those fly-by-night operations that sends out mass incompetently drafted DMCA requests on behalf of clients (it's important not to do any competent lawyering, because that would reduce the profit margin). In this case they were hired by a company called Adam & Eve (NSFW, obviously) and sent the letters on that company's behalf.
In theory submitting a false DMCA request is illegal. And there are theoretically plausible civil suits as well, if someone submits a false or reckless DMCA request that damages your business. But has anyone in history actually suffered any repercussions from submitting false DMCA requests? It seems people submit false ones all the time, and not only borderline mistakes but things ranging from reckless disregard for the truth to outright maliciously false requests (e.g. for SEO purposes). Yet I have never heard of anyone being prosecuted or sued for it.
You could call it that, sure, but in practice many people studying the possibility of life on other planets refer to their specialty as "astrobiology". For example, the University of Washington has an astrobiology program.
Some are less sci-fi than others though. An astrobiologist studying the possibility of life on Mars at least has some pretty concrete work they can do: there is new data coming in, there are experiments that can be performed with probes to confirm or rule out some theories, etc. An astrobiologist studying the possibility of star-eating lifeforms in deep space has... less concrete work to do.
Yeah, the FCC has a bit of a garbage-in, garbage-out problem with the whole complaint system. The proportion of knowledgeable complaints about things like signal interference or fraudulent business practices is pretty low. Lots more people use the FCC complaint system to file a complaint about curse words or a flash of a breast on network TV.
Slashdot uses a more insidious form of "soft-blocking" where rather than being outright blocked, certain users are redirected to beta.slashdot.org.
That's Google's play, with the Chromebooks...
It looks like a judgment was actually entered for $80m, so saying that you got an $80m judgment is accurate. Now whether you can collect on that judgment is another story. It's possible that they should have informed shareholders of the low likelihood of the judgment being paid, via an SEC filing.