I generally stand by my assertion of FUD but it's worth noting that the replies and discussion below my original comment are interesting, correct technical inaccuracies and vagueness on my part and are generally important reading. Don't read my original comment on it's own. The replies by others should be modded up to at least the same level as my original comment but I can't do that myself.
Weirdly, looking at those other comments, it seems like some people not only read TFA but also the previous one! Wonders never cease!
But just how invasive is it? What technique do they actually use to do it I wonder? I guess they could "simply" replace the standard library implementation of the Trident engine with one of their own? That would at least use an established interface though presumably there'd be potential holes where unwritten rules of this interface were violated? Or do they reach into IE at runtime and tweak things; that would be very nasty.
Either way it would seem that they're quite likely to have increased the likelihood (!) of there being exploits in there somewhere. I don't see that it's a doubling as MS claimed but I can understand the rhetorical reasons for saying that. And it does sound like it could well make things "worse" for some value of worse.
Ah, OK. That's a bit manky but it does explain where the bigger attack suface comes from I guess - you get to choose which renderer you attack. It's not a doubling in attackable code, since only the renderer is swappable. But there are two renderers and you can choose which one to attack. Ewww, though.
You should get modded up. Yes, others have also mentioned that it's just webkit (and V8, I guess). So Chrome's sandboxing isn't there, in that case. But it's still not clear to me why this would necessarily be worse. The MS statement still smells like FUD to me - they're basically suggesting that Chrome's rendering engine is obviously less secure than IE's but not really saying why. And if they're omitted the complexity of the rest of Chrome and just replaced the rendering engine it's still not really clear to me why the total attack surface would be any greater - there's still the same number of components in there as in the vanilla browser, just mixed up a bit.
I realise that's the risk they're referring to. But whether it works like that really depends on how it's architected.
If Chrome is using IE facilities to interact with the outside world, then that's exposing you to bugs in those IE facilities. If Chrome was using its own HTTP implementation, etc and basically just acting as an independent browser that happens to be embedded in an IE window then Chrome is going to be the one exposing bugs to the outside world.
I assume that it is somehow using IE facilities so that you get the impression of an integrated browser, which makes it more likely that IE is also being exposed for attack. But it's not instantly obvious that that's definitely the case. Maybe if I'd read the article about the Chrome Frame when that came out...;-)
"Given the security issues with plugins in general and Google Chrome in particular"
O RLY?
I'm happy to believe that IE8 actually has a good security model. I'm happy to believe that Chrome is not without flaws. But, really, Google have gone through fairly considerable pain and implemented quite strict sandboxing techniques for Chrome, to contain any problems in the renderer. It's pretty solid. Maybe it's better than IE8, maybe not. But just hand waving and going "Oh yes, *especially* Chrome" as if it's common knowledge that it's insecure is simply FUD.
The point about increasing the attack surface area seems more valid, perhaps, though it really depends on how this plugin works. If there are really twice as many places available at once then yes, that is a worry. If you'd have to get through Chrome's security and then through IE8's security, that actually sounds quite good. Possibly the biggest security worry I see is in encouraging users to think that installing a large, scary plugin that basically replaces the guts of their browser is a normal occurrence that will make their internet experience better.
Well, the title was not very helpful - it came from the first of the linked articles. The second was a bit more informative but still quite vague.
The interesting thing here seems to be that they're planning to tunnel multiple protocols over the optical link. So you might be hanging monitors, USB devices, SATA drives, whatever off this link. It'd be a bridge that could tunnel your device connections to somewhere quite physically distant, using only a single cable. One assumes (maybe this is a big assumption) that an important part of the effort is in getting hardware that can efficiently do the encapsulation / decapsulation of the various device protocols. I'm not entirely sure why you couldn't do this over a 10Gb ethernet link, with some kind of protocol for tunneling over ethernet. I'd speculate that it'd make the controller chips more expensive if you did this but I really don't know. Everything is guesswork anyhow, until they give us more information.
The main thing I can see this being useful for is stuff like blade desktops - the real computer you're using as your desktop is just a blade server in a chilled room, with sysadmins leaving it regular sacrificial offerings for optimal uptime. The monitor, USB devices, everything would then be connected to the blade desktop by a single optical cable. Only one slim cable to route for each desktop, everything runs over it so the "desktop" can still have functional USB ports etc. Having an optical cable seems like it would be ideal for that kind of scenario. The ultimate thin client. If you have multiple Light Peak ports on a single blade then perhaps you could get multiple virtual machines to drive separate workstations, making your datacentre density even higher.
Other stuff it might be interesting for is some kind of cheap (?) high speed networking, home media servers, low cost SAN hardware, etc. Depending on how they do it of course. But if they made it generic enough it would be really interesting for a lot of applications that are now priced out of the reach of individuals and probably also small businesses.
I probably don't really want an existing DE on my mobile phone (for instance), I agree with you on that. But there's a lot of space between Moblin's approach (which already uses a custom DE that's specialised for netbook-class devices) and Android's approach (which replaces almost everything in the stack, as well as the UI). I'd also like for the primary supported method of writing applications to not be a strange combination of Java and a custom bytecode interpreter / JIT - that's the way Android has done it although I had the impression they were moving to support native applications.
If Moblin rewrites the entire user interface and doesn't default to using any "normal" Linux apps, it will still be *way* closer to "normal" Linux than Android is. Android doesn't use glibc, AFAIK - it doesn't even use X.org for display. Moblin on a phone would "merely" have an unfamiliar interface and apps, where Android is basically unfamiliar to me in every way - it's a significantly larger change than just the UI level.
I'm not a normal case, I suppose, in that I like to hack about with devices. However, it seems to me that the closer-to-vanilla environment provided by Moblin is going to be easier to get existing OSS developers working on and I'd like to benefit from their work too.
I'd rather buy Moblin than Android on a mobile device. Android replaces basically every part of what we usually call "Linux", except for the kernel (which of course actually *is* Linux). Moblin has a heavily custom desktop environment but other than that it seems like a reasonably "normal" distribution. If I were to do any hacking on the device I'd bought, I'd like it to be a familiar environment. If I'm downloading others' apps I'd feel more confident in getting a good range of apps if they can code in a familiar environment.
Android's good because it's an open platform. I can easily believe that for really resource-constrained apps it's better than Moblin. But on anything that can handle it, I'd rather have a "real" distro than Android. The diversity of having multiple mobile platforms is a good thing; I just personally would rather be able to run a familiar Unix-like environment on all my devices, even if they use a custom front-end to fit the form factor. Improvements to infrastructure (kernel, X.org, shell, apps, whatever) required for a small device are something that I'd like to see integrated upstream so that everyone benefits.
Thank you for your lovely replies. It's been really nice to engage with somebody who is interested in other points of view. *Really* listening to stuff you disagree with is one of the most difficult skills to master, I think. It's not something I'm as good at as I'd like to be but you seem to have the knack!
I'm sure your daughter will continue to learn fast, especially if she's as open minded as you. 14 is a fairly long time ago for me and there were a lot of changes to get used to all at once - not an easy age to be. It took me a lot longer than that to really start looking hard at the world and trying to think through my viewpoints; it's still something I'm working on doing really properly!
It's fun being a geek:-) Take care, maybe I will see you posting here again some time.
Yes - but moving them out of the kernel will not reduce the instruction cache space required, which was one of the things Linus noted. Actually, it might even increase it.
You speak a lot of truth. An "us vs them" dynamic is a horrible thing to have within a company as it creates an unhappy atmosphere and potentially reduces communication further, impairing effectiveness of the company as a whole. In defense of the (seemingly eternal) engineering vs marketing squabble I'd note that there seem to be a fair number of companies where marketing is the tail, wagging the dog. In an aggressive company that's trying to win lots of contracts, marketing has a motivation to sell impossible things and this has the potential to cause serious tension.
In my opinion, it really ought to be management's job to sort this out. In an ideal world, the management aren't just there to monitor what people do, or walk about PHB-style and disrupt stuff. Words like "facilitate" get horribly weasel-ified and overused but the fact is that it *is* something they should be doing. Facilitating communication between different groups with different work styles and personalities. Setting the priorities so that nobody can reasonably feel under-represented. A strong manager ought to make an effort to compensate for the persuasiveness of Marketing arguments over Engineering, they ought to make sure the two divisions have appropriate contact - perhaps not too direct - and that there are staff (if not management themselves) who can "translate" between the two to find a fair deal.
When marketing and engineering talk too directly without understanding each other, I suspect that's always likely to create conflict - they have very different priorities. If one or the other is disproprotionately listened to or handed power or paid, that'll create resentment. The employees must bear some responsibility for not creating an adversarial workplace but the managers should be working *really hard* to mitigate the root causes of an adversarial environment - intolerance, unfairness, poor communication, etc.
Essentially, yes. But I *think* it's more than that, which is why I found the HURD so exciting when I read about it. FUSE is excellent but what they've done is grafted a particular capability - writing filesystems in userspace and mounting them as non-root - into an existing OS.
With HURD I had the impression they'd gone a *lot* more general - instead of asking "How do we let users write filesystems?" they asked "How do we let users extend the OS?". Filesystems are just one area of the OS you might want to extend in order to customise your environment.
With that design userspace filesystems will Just Work - as they do in Linux. But so, potentially, would a whole load of other interesting kinds of extensions because they weren't just solving the problem for filesystems.
Filesystems were just the specific example given when I read about the HURD architecture - Linux didn't include FUSE at that point, so it was more of a "killer feature" to be able to support userspace filesystems. I don't know what else they'd enabled with HURD but with a sensibly-designed system on similar principles I imagine being able to do stuff like:
* Add experimental new system calls you're implementing. Maybe implement Windows system calls directly, if you have a need to run Windows apps. The availability of alternate "personalities" is one thing microkernels could do well, if the OS you're running supports it. * Implement custom network protocols and have your apps use them just like "native" socket types * Implement new shared memory abstractions that suit your own processes' requirements particularly well
But really, with a well-designed system, there'd be few limits on what you could implement as an unprivileged user. The flexibility (and, in some cases, performance - though that's more debatable) would be incredible.
I don't know enough able VMS to be able to judge, really.
I'd think you could probably through away quite a lot of Linux and replace it with un-Unix-y stuff and still find it a more manageable project than a complete reimplementation. Maybe.
It'd be worth having the device drivers (and filesystems, perhaps) available. Question is just how poor of a fit the upper layers of Linux would be (replace the syscall interface? Virtual memory management? Process / threading code?). If you were prepared to do a lot of hard work, all of those could be "fixed" for different semantics but it'd be a heckuva lot harder once you got into stuff like the virtual memory subsystem:-(
This is something I'm really unable to judge, never having had the good fortune to play with VMS. It is a system I intend to learn more about.
I'm sorry I wasn't able to reply earlier as I was traveling over the weekend. I'm going to have be brief right now as it's been a long day and have only just got back into town.
Thank you for your pleasant and reasonable reply. There's a lot of emotion around these topics and it's often difficult or impossible to find people who are willing to really *talk* about the issues involved.
I wouldn't necessarily say, despite my belief in my own nature, that I am exactly immune to images of violence. It's something I remain wary of and if I thought it was affecting me negatively then I would probably have to quit. So far I've been happy to observe that my reactions to real life violence have not been reduced, despite my acceptance of video game violence. I am in agreement with you that others may be more easily influence. Despite my opposition to banning most imagery, I'm certainly in favour of careful regulation of it, within certain boundaries. I do approve of the age regulation schemes used for movies and games. I think that games (and movies) showing particularly graphic violence ought to be restricted to legal adults. It's also worth the government and industry making sure to educate parents about computer games, since I'm sure some don't realise that they are not all suitable for minors. I don't believe in over-protecting children but I think it's pretty important not to expose them to inappropriate material at a critical time in their moral and intellectual development.
By around the age of 18 (give or take - there's certainly room for argument on the specific age) I consider that core moral development of a person has mostly occurred, so it reduces the chance of their perceptions being warped or their blurring the line between fantasy and reality. Also, once you're a legal adult you are able to indulge in a wide variety of media and behaviour - a freedom we grant to adults since we believe they are able to make informed choices and take responsibility for real-world actions. My - uninformed by science or psychology, so this is *mere idle gossip* from a public policy point of view - belief is that those who are unhealthily interested in violence are liable to look for outlets in whatever is available. If video games were not available, there would be other ways to indulge this - movies, books, art even. Moreover there are extremely violent and *real* images that we actually wish to permit access to, for instance through normal television news, so that would always be available. So we can never completely deny access to this imagery to those who thirst for or would be warped by violence.
Actually, though, to a certain extent I've come round to agreeing with your original support of the ban in this instance. Why? Assuming other comments here are correct (yes, yes, it's Slashdot, I must be new here, etc!) it would appear to be the case that the Aussie classifiers don't have the option of rating the game for 18+ only. They can do that for films, it seems, but not for games. The first Left 4 Dead game was available at an 18 rating here in the UK. The sequel discussed here looks significantly more violent - violent enough for me to find it disturbing, despite having enjoyed the original. Although I wouldn't approve of preventing sale of the game to legal adults I definitely wouldn't want to see it sold to ages 15+, which appears to be the only other option they could realistically have taken. My favourite solution would really be for the game not to be banned but for the 18+ classification to be available to the classification board so that games - like movies - can be restricted to adults-only where appropriate.
I'm sorry you had to endure your wartime experience and believe you deserve respect for what you've endured.
It's possibly worth noting that the game in question is not a war game but I don't think that probably changes your core objection, which as I understand it is against making violence against humans (or human-looking things) and personal peril a recreational activity. I should note that, politically, I'm generally in favour of not banning things where reasonably possible. Why? Well, my core reasoning is based on the principle of freedom of speech. I prefer for the state to minimise its use of control over its citizens, even if well-intentioned, as this minimises the temptation / opportunity to increase their own power at the expense of the citizenry.
I'd just like to explain what violent games have done to me, psychologically. Before I started playing them, I was squeamish about even swatting flies. I avoided pretty much any game with remotely realistic representations of gore or death, not because I was morally opposed to their *existence* or to people who play them but because I personally felt uncomfortable with them. Since then I've been persuaded into playing them and now enjoy them regularly, although I must admit that the most graphics / violent games make me uncomfortable and I still prefer to avoid those. The psychological change that's resulted? The violence in the game doesn't feel as real to me. But this is not, as some opponents of video games feels, because I've become more accepting of violence in general or because I've lost empathy for images of injured humans. Rather I've dehumanised the computer-generated pixels on the screen - I don't see video game violence as realistic anymore since it is simply a bunch of bits and computations inside a computer chip and some flickering lights on a screen. So for that reason it doesn't bother me as much. Real world violence remains an entirely different matter - I still hate killing insects and avoid doing so wherever possible, I abhor violence against humans and I hate to see suffering. This is because I know that real world violence is *real*, actual suffering is happening, and it pains me to think of that.
This is obviously merely anecdote. Also, as I understand it psychologists do not rate a personal evaluation of one's own thought processes as a very convincing way of determining what's really going on. But I think it's worth noting that, whilst changes can occur as a result of playing violent games, they're not necessarily going to be the immediately obvious and clearly detrimental ones that some people expect. This is, I think, a major reason why there's a fairly acrimonious split between people who (quite understandably) think that violent games present images of unacceptable acts and the people who cannot see the problem with them at all. I think they're both right - they are sometimes images of unacceptable acts but that does not *necessarily* make the images themselves unacceptable. My personal position, as you've no doubt inferred, is that real violence is usually morally unacceptable (avoiding thorny philosophical questions about how it's sometimes justified) but that images do no direct harm and are therefore acceptable to me even though I find some of them disturbing and would personally prefer not to see them.
In the Unix -> Linux style, another OS to be ressurrected as a GPL-licensed reimplementation is VMS. Whilst the Open in OpenVMS doesn't refer to Open Source, the Free in FreeVMS really does mean Freedom.
It appears to be based on Linux kernel code but implementing VMS-like behaviour on top of that. I've always heard that (if it wasn't for Unix), VMS would be *the* hacker OS. Plus Unix was popular because its code was pretty commonly available in the early days. VMS itself sounds awesome in a number of ways and I'm aware that it's still used in the Real World, although you rarely observe it directly.
FreeVMS are looking for developers, it would seem...
The fact that they're building a microkernel-based system helps. Mach presumably gives them features they need for that. But they *could* have just done what a lot of other microkernel-based systems have done and plonked a large monolithic Unix server on top. The impression that I'd had was that they instead designed things so that it was easy to replace individual components on a per-user basis.
I'm not especially familiar with Mach, other than some of the general principles. I suppose it's possible that even if a monolithic Unix server was providing most facilities it could still be possible to direct filesystem-related messages somewhere else? I don't really know.
The Hurd design was, as I understood it, really intended to make user-implemented filesystem servers be first class components (albeit with potentially reduced privileges), rather than just an alternate option.
Uh, did I manage to make sense, or have I missed the point?
Hurd got to a state where it was actually usable - there was a Debian distro of it, you could run X, you could run various applications, it was *real*. But that version was based on the Mach microkernel. Since then they went down the route of porting to the L4 microkernel (generally considered faster but I suspect YMMV depending on design & implementation of what you run on top of it). That work had some interesting ideas but last rumour I'd heard was that they'd stopped *that* port and that someone was working on a new microkernel that better fit their needs.
Hurd's design had nice features. For instance, it's fundamental to the design that users can replace OS components with their own, so custom userspace filesystems were easily supported. Linux gained this capability through FUSE but Hurd had it baked naturally into the design AFAIK.
I'd be quite interested in playing with Hurd but my main issue is that I don't perceive there being a very cohesive effort around it now, so I wouldn't know how to contribute or whether it would help at all. That might *just* be my perception, however the project has manifestly been "on the way" for a very long time.
The article also compared Zones to VServers and noted that the latter aren't in the Linux kernel and require patches. This is true but Linux contains OS-level virtualisation of it's own, which you can use via the LXC tools: http://lxc.sourceforge.net/
The VServers people expressed disinterest in merging their stuff into mainline. However, a combination of core Linux developers and OpenVZ developers have been working for some time on integrating full OS-level virtualisation into Linux, with the result that you can now run virtual machines on mainline Linux without any kernel patches. Not all the features of OpenVZ are supported (e.g. I think OpenVZ lets you do live migrations) but I'm not sure if Zones supports these either.
It's not surprising the author didn't know about the Linux container stuff, though - not much noise has been made about it. Presumably this is partly because the OpenVZ people haven't switched over to using it instead of their external patches yet. It is perhaps less mature / well-tested than Zones but nevertheless it is there, in the kernel, and you can just go ahead and use it if your distro built in support.
> OpenSolaris restores that warm fuzzy feeling from the Windows days where you get to waste hours (days? weeks?) > installing 3rd party proprietary drivers and feeling like a computer expert instead of things "just working" out of the box.
An interesting thing I've noticed - Linux's not supporting a stable driver ABI is often cited as a reason for a lack of hardware support. Solaris has a stable driver ABI, FreeBSD has a stable driver ABI and yet I doubt that even if you install every 3rd party driver you can find they would support as many devices as Linux. A note on the fairness of this comparison: Linux has a larger userbase, so obviously there'll be more drivers for it. And yes, perhaps it's possible Linux would have even better driver support if it had a stable driver ABI.
The point I think is worth making is that the lack of a stable driver ABI gets cited as a reason why Linux sometimes has worse driver support than Windows. The theory being, AFAIK, that supporting a moving target is too much effort and is probably the thing that's turning off device manufacturers. I think looking at the other Unix-likes demonstrates that a stable driver ABI, whilst useful, is not necessarily the magic ingredient for widespread support that some people suggest. I'm sure it helps - but being able to continuously clean up the driver API (and making the relevant changes, for free, for all drivers in mainline) so that the drivers are easier to write also helps and doesn't require a massive change in the way Linux development is done.
Linux containers provide similar functionality to Solaris Zones: http://lxc.sourceforge.net/ They're a younger project but the support for them is in mainline Linux and you can do some pretty cool stuff with them. One thing that's nice (and I don't know if Zones can do this) is that you don't have to virtualise every aspect of a container, so for instance you can just isolate at the filesystem level if that's all you needed. Solaris Zones is capable of running apps for another OS within a Zone, using their system call compatibility layer. Linux has a system call compatibility layer but I don't know if it can run a complete other-OS userspace as Zones can (e.g. Zones can run CentOS or RHEL userland in a Zone, on top of the Solaris kernel).
Most everyone here is going to have heard of Btrfs but here it is again anyhow: http://btrfs.wiki.kernel.org/index.php/Main_Page It gives you similar stuff (checksumming, RAID-in-filesystem, writeable snapshots) to ZFS but again is a younger project. It's also in mainline Linux so you can play with it if you have a recent kernel (don't trust it with critical data, yet).
System Tap is one (of a number) DTrace-ish system for Linux: http://sourceware.org/systemtap/ I understand it'll run on basically any non-stoneage kernel but to get all of the juicy features you would (I *think*) need to patch your kernel. This is the only one of these projects for which full functionality appears not to be completely in mainline. Various distributions include it, so you can probably install a package and try it out (at least in a limited form, depending on your kernel).
A notable feature here is that none of these sound quite as mature as the Solaris equivalents. Not all of them constitute "copying", however - for instance, container-like solutions for Linux predate Solaris Zones by years (and BSD Jails, a similar concept, are almost certainly even older). I'm not sure on the dates of the others.
Oops, embarrassing, I always thought it was. Perhaps I just picked up the wrong idea somewhere - Google found me a whole raft of people who thought BeOS was a microkernel.
I'm actually a bit disappointed, in a way. I'm a fan of variety in operating systems and being a hybrid kernel (which I'd generally count as a different way of structuring what I'd call a monolithic kernel, though people seem to vary on their uses of these terms) is less different to the current popular OSes than a microkernel would have been:-(
Do you have a link for that FAQ btw, I didn't have much luck finding it on their newly revamped site. It's be really nice to see some more general architectural documentation about their kernel, which I should perhaps go hunting for. I grubbed around in their kernel code for a while recently but I just got an overview of what the APIs generally looked like and what filesystems were there.
Slashdot Mirror
I generally stand by my assertion of FUD but it's worth noting that the replies and discussion below my original comment are interesting, correct technical inaccuracies and vagueness on my part and are generally important reading. Don't read my original comment on it's own. The replies by others should be modded up to at least the same level as my original comment but I can't do that myself.
Weirdly, looking at those other comments, it seems like some people not only read TFA but also the previous one! Wonders never cease!
Good point.
But just how invasive is it? What technique do they actually use to do it I wonder? I guess they could "simply" replace the standard library implementation of the Trident engine with one of their own? That would at least use an established interface though presumably there'd be potential holes where unwritten rules of this interface were violated? Or do they reach into IE at runtime and tweak things; that would be very nasty.
Either way it would seem that they're quite likely to have increased the likelihood (!) of there being exploits in there somewhere. I don't see that it's a doubling as MS claimed but I can understand the rhetorical reasons for saying that. And it does sound like it could well make things "worse" for some value of worse.
Ah, OK. That's a bit manky but it does explain where the bigger attack suface comes from I guess - you get to choose which renderer you attack. It's not a doubling in attackable code, since only the renderer is swappable. But there are two renderers and you can choose which one to attack. Ewww, though.
You should get modded up. Yes, others have also mentioned that it's just webkit (and V8, I guess). So Chrome's sandboxing isn't there, in that case. But it's still not clear to me why this would necessarily be worse. The MS statement still smells like FUD to me - they're basically suggesting that Chrome's rendering engine is obviously less secure than IE's but not really saying why. And if they're omitted the complexity of the rest of Chrome and just replaced the rendering engine it's still not really clear to me why the total attack surface would be any greater - there's still the same number of components in there as in the vanilla browser, just mixed up a bit.
Ah, OK, I hadn't realised that about it. Because of not reading TFPA (the fine previous article) on the plugin.
But - as you say - it's not really clear how Chrome makes things worse.
Also, it sounds like it's not then a case of:
Total vulnerabilities = IE8 vulnerabilities + Chrome vulnerabilities
but rather
Total vulnerabilities = IE8 vulnerabilities - IE8 renderer vulnerabilities + Chrome vulnerabilities - Every Chrome vulnerability that's *not* in the renderer
And it's not obvious to me that this total number is any worse than either browser in "vanilla" state would be expected to have.
I realise that's the risk they're referring to. But whether it works like that really depends on how it's architected.
If Chrome is using IE facilities to interact with the outside world, then that's exposing you to bugs in those IE facilities. If Chrome was using its own HTTP implementation, etc and basically just acting as an independent browser that happens to be embedded in an IE window then Chrome is going to be the one exposing bugs to the outside world.
I assume that it is somehow using IE facilities so that you get the impression of an integrated browser, which makes it more likely that IE is also being exposed for attack. But it's not instantly obvious that that's definitely the case. Maybe if I'd read the article about the Chrome Frame when that came out ... ;-)
"Given the security issues with plugins in general and Google Chrome in particular"
O RLY?
I'm happy to believe that IE8 actually has a good security model. I'm happy to believe that Chrome is not without flaws. But, really, Google have gone through fairly considerable pain and implemented quite strict sandboxing techniques for Chrome, to contain any problems in the renderer. It's pretty solid. Maybe it's better than IE8, maybe not. But just hand waving and going "Oh yes, *especially* Chrome" as if it's common knowledge that it's insecure is simply FUD.
The point about increasing the attack surface area seems more valid, perhaps, though it really depends on how this plugin works. If there are really twice as many places available at once then yes, that is a worry. If you'd have to get through Chrome's security and then through IE8's security, that actually sounds quite good. Possibly the biggest security worry I see is in encouraging users to think that installing a large, scary plugin that basically replaces the guts of their browser is a normal occurrence that will make their internet experience better.
Well, the title was not very helpful - it came from the first of the linked articles. The second was a bit more informative but still quite vague.
The interesting thing here seems to be that they're planning to tunnel multiple protocols over the optical link. So you might be hanging monitors, USB devices, SATA drives, whatever off this link. It'd be a bridge that could tunnel your device connections to somewhere quite physically distant, using only a single cable. One assumes (maybe this is a big assumption) that an important part of the effort is in getting hardware that can efficiently do the encapsulation / decapsulation of the various device protocols. I'm not entirely sure why you couldn't do this over a 10Gb ethernet link, with some kind of protocol for tunneling over ethernet. I'd speculate that it'd make the controller chips more expensive if you did this but I really don't know. Everything is guesswork anyhow, until they give us more information.
The main thing I can see this being useful for is stuff like blade desktops - the real computer you're using as your desktop is just a blade server in a chilled room, with sysadmins leaving it regular sacrificial offerings for optimal uptime. The monitor, USB devices, everything would then be connected to the blade desktop by a single optical cable. Only one slim cable to route for each desktop, everything runs over it so the "desktop" can still have functional USB ports etc. Having an optical cable seems like it would be ideal for that kind of scenario. The ultimate thin client. If you have multiple Light Peak ports on a single blade then perhaps you could get multiple virtual machines to drive separate workstations, making your datacentre density even higher.
Other stuff it might be interesting for is some kind of cheap (?) high speed networking, home media servers, low cost SAN hardware, etc. Depending on how they do it of course. But if they made it generic enough it would be really interesting for a lot of applications that are now priced out of the reach of individuals and probably also small businesses.
I probably don't really want an existing DE on my mobile phone (for instance), I agree with you on that. But there's a lot of space between Moblin's approach (which already uses a custom DE that's specialised for netbook-class devices) and Android's approach (which replaces almost everything in the stack, as well as the UI). I'd also like for the primary supported method of writing applications to not be a strange combination of Java and a custom bytecode interpreter / JIT - that's the way Android has done it although I had the impression they were moving to support native applications.
If Moblin rewrites the entire user interface and doesn't default to using any "normal" Linux apps, it will still be *way* closer to "normal" Linux than Android is. Android doesn't use glibc, AFAIK - it doesn't even use X.org for display. Moblin on a phone would "merely" have an unfamiliar interface and apps, where Android is basically unfamiliar to me in every way - it's a significantly larger change than just the UI level.
I'm not a normal case, I suppose, in that I like to hack about with devices. However, it seems to me that the closer-to-vanilla environment provided by Moblin is going to be easier to get existing OSS developers working on and I'd like to benefit from their work too.
I'd rather buy Moblin than Android on a mobile device. Android replaces basically every part of what we usually call "Linux", except for the kernel (which of course actually *is* Linux). Moblin has a heavily custom desktop environment but other than that it seems like a reasonably "normal" distribution. If I were to do any hacking on the device I'd bought, I'd like it to be a familiar environment. If I'm downloading others' apps I'd feel more confident in getting a good range of apps if they can code in a familiar environment.
Android's good because it's an open platform. I can easily believe that for really resource-constrained apps it's better than Moblin. But on anything that can handle it, I'd rather have a "real" distro than Android. The diversity of having multiple mobile platforms is a good thing; I just personally would rather be able to run a familiar Unix-like environment on all my devices, even if they use a custom front-end to fit the form factor. Improvements to infrastructure (kernel, X.org, shell, apps, whatever) required for a small device are something that I'd like to see integrated upstream so that everyone benefits.
Heard you like to fly, so we put wiimotes in your MMO so you can fly while you fly!
Worrying as my meme habit may be to you, it really scares me.
Thank you for your lovely replies. It's been really nice to engage with somebody who is interested in other points of view. *Really* listening to stuff you disagree with is one of the most difficult skills to master, I think. It's not something I'm as good at as I'd like to be but you seem to have the knack!
I'm sure your daughter will continue to learn fast, especially if she's as open minded as you. 14 is a fairly long time ago for me and there were a lot of changes to get used to all at once - not an easy age to be. It took me a lot longer than that to really start looking hard at the world and trying to think through my viewpoints; it's still something I'm working on doing really properly!
It's fun being a geek :-) Take care, maybe I will see you posting here again some time.
Yes - but moving them out of the kernel will not reduce the instruction cache space required, which was one of the things Linus noted. Actually, it might even increase it.
You speak a lot of truth. An "us vs them" dynamic is a horrible thing to have within a company as it creates an unhappy atmosphere and potentially reduces communication further, impairing effectiveness of the company as a whole. In defense of the (seemingly eternal) engineering vs marketing squabble I'd note that there seem to be a fair number of companies where marketing is the tail, wagging the dog. In an aggressive company that's trying to win lots of contracts, marketing has a motivation to sell impossible things and this has the potential to cause serious tension.
In my opinion, it really ought to be management's job to sort this out. In an ideal world, the management aren't just there to monitor what people do, or walk about PHB-style and disrupt stuff. Words like "facilitate" get horribly weasel-ified and overused but the fact is that it *is* something they should be doing. Facilitating communication between different groups with different work styles and personalities. Setting the priorities so that nobody can reasonably feel under-represented. A strong manager ought to make an effort to compensate for the persuasiveness of Marketing arguments over Engineering, they ought to make sure the two divisions have appropriate contact - perhaps not too direct - and that there are staff (if not management themselves) who can "translate" between the two to find a fair deal.
When marketing and engineering talk too directly without understanding each other, I suspect that's always likely to create conflict - they have very different priorities. If one or the other is disproprotionately listened to or handed power or paid, that'll create resentment. The employees must bear some responsibility for not creating an adversarial workplace but the managers should be working *really hard* to mitigate the root causes of an adversarial environment - intolerance, unfairness, poor communication, etc.
Essentially, yes. But I *think* it's more than that, which is why I found the HURD so exciting when I read about it. FUSE is excellent but what they've done is grafted a particular capability - writing filesystems in userspace and mounting them as non-root - into an existing OS.
With HURD I had the impression they'd gone a *lot* more general - instead of asking "How do we let users write filesystems?" they asked "How do we let users extend the OS?". Filesystems are just one area of the OS you might want to extend in order to customise your environment.
With that design userspace filesystems will Just Work - as they do in Linux. But so, potentially, would a whole load of other interesting kinds of extensions because they weren't just solving the problem for filesystems.
Filesystems were just the specific example given when I read about the HURD architecture - Linux didn't include FUSE at that point, so it was more of a "killer feature" to be able to support userspace filesystems. I don't know what else they'd enabled with HURD but with a sensibly-designed system on similar principles I imagine being able to do stuff like:
* Add experimental new system calls you're implementing. Maybe implement Windows system calls directly, if you have a need to run Windows apps. The availability of alternate "personalities" is one thing microkernels could do well, if the OS you're running supports it.
* Implement custom network protocols and have your apps use them just like "native" socket types
* Implement new shared memory abstractions that suit your own processes' requirements particularly well
But really, with a well-designed system, there'd be few limits on what you could implement as an unprivileged user. The flexibility (and, in some cases, performance - though that's more debatable) would be incredible.
I don't know enough able VMS to be able to judge, really.
I'd think you could probably through away quite a lot of Linux and replace it with un-Unix-y stuff and still find it a more manageable project than a complete reimplementation. Maybe.
It'd be worth having the device drivers (and filesystems, perhaps) available. Question is just how poor of a fit the upper layers of Linux would be (replace the syscall interface? Virtual memory management? Process / threading code?). If you were prepared to do a lot of hard work, all of those could be "fixed" for different semantics but it'd be a heckuva lot harder once you got into stuff like the virtual memory subsystem :-(
This is something I'm really unable to judge, never having had the good fortune to play with VMS. It is a system I intend to learn more about.
I'm sorry I wasn't able to reply earlier as I was traveling over the weekend. I'm going to have be brief right now as it's been a long day and have only just got back into town.
Thank you for your pleasant and reasonable reply. There's a lot of emotion around these topics and it's often difficult or impossible to find people who are willing to really *talk* about the issues involved.
I wouldn't necessarily say, despite my belief in my own nature, that I am exactly immune to images of violence. It's something I remain wary of and if I thought it was affecting me negatively then I would probably have to quit. So far I've been happy to observe that my reactions to real life violence have not been reduced, despite my acceptance of video game violence. I am in agreement with you that others may be more easily influence. Despite my opposition to banning most imagery, I'm certainly in favour of careful regulation of it, within certain boundaries. I do approve of the age regulation schemes used for movies and games. I think that games (and movies) showing particularly graphic violence ought to be restricted to legal adults. It's also worth the government and industry making sure to educate parents about computer games, since I'm sure some don't realise that they are not all suitable for minors. I don't believe in over-protecting children but I think it's pretty important not to expose them to inappropriate material at a critical time in their moral and intellectual development.
By around the age of 18 (give or take - there's certainly room for argument on the specific age) I consider that core moral development of a person has mostly occurred, so it reduces the chance of their perceptions being warped or their blurring the line between fantasy and reality. Also, once you're a legal adult you are able to indulge in a wide variety of media and behaviour - a freedom we grant to adults since we believe they are able to make informed choices and take responsibility for real-world actions. My - uninformed by science or psychology, so this is *mere idle gossip* from a public policy point of view - belief is that those who are unhealthily interested in violence are liable to look for outlets in whatever is available. If video games were not available, there would be other ways to indulge this - movies, books, art even. Moreover there are extremely violent and *real* images that we actually wish to permit access to, for instance through normal television news, so that would always be available. So we can never completely deny access to this imagery to those who thirst for or would be warped by violence.
Actually, though, to a certain extent I've come round to agreeing with your original support of the ban in this instance. Why? Assuming other comments here are correct (yes, yes, it's Slashdot, I must be new here, etc!) it would appear to be the case that the Aussie classifiers don't have the option of rating the game for 18+ only. They can do that for films, it seems, but not for games. The first Left 4 Dead game was available at an 18 rating here in the UK. The sequel discussed here looks significantly more violent - violent enough for me to find it disturbing, despite having enjoyed the original. Although I wouldn't approve of preventing sale of the game to legal adults I definitely wouldn't want to see it sold to ages 15+, which appears to be the only other option they could realistically have taken. My favourite solution would really be for the game not to be banned but for the 18+ classification to be available to the classification board so that games - like movies - can be restricted to adults-only where appropriate.
I'm sorry you had to endure your wartime experience and believe you deserve respect for what you've endured.
It's possibly worth noting that the game in question is not a war game but I don't think that probably changes your core objection, which as I understand it is against making violence against humans (or human-looking things) and personal peril a recreational activity. I should note that, politically, I'm generally in favour of not banning things where reasonably possible. Why? Well, my core reasoning is based on the principle of freedom of speech. I prefer for the state to minimise its use of control over its citizens, even if well-intentioned, as this minimises the temptation / opportunity to increase their own power at the expense of the citizenry.
I'd just like to explain what violent games have done to me, psychologically. Before I started playing them, I was squeamish about even swatting flies. I avoided pretty much any game with remotely realistic representations of gore or death, not because I was morally opposed to their *existence* or to people who play them but because I personally felt uncomfortable with them. Since then I've been persuaded into playing them and now enjoy them regularly, although I must admit that the most graphics / violent games make me uncomfortable and I still prefer to avoid those. The psychological change that's resulted? The violence in the game doesn't feel as real to me. But this is not, as some opponents of video games feels, because I've become more accepting of violence in general or because I've lost empathy for images of injured humans. Rather I've dehumanised the computer-generated pixels on the screen - I don't see video game violence as realistic anymore since it is simply a bunch of bits and computations inside a computer chip and some flickering lights on a screen. So for that reason it doesn't bother me as much. Real world violence remains an entirely different matter - I still hate killing insects and avoid doing so wherever possible, I abhor violence against humans and I hate to see suffering. This is because I know that real world violence is *real*, actual suffering is happening, and it pains me to think of that.
This is obviously merely anecdote. Also, as I understand it psychologists do not rate a personal evaluation of one's own thought processes as a very convincing way of determining what's really going on. But I think it's worth noting that, whilst changes can occur as a result of playing violent games, they're not necessarily going to be the immediately obvious and clearly detrimental ones that some people expect. This is, I think, a major reason why there's a fairly acrimonious split between people who (quite understandably) think that violent games present images of unacceptable acts and the people who cannot see the problem with them at all. I think they're both right - they are sometimes images of unacceptable acts but that does not *necessarily* make the images themselves unacceptable. My personal position, as you've no doubt inferred, is that real violence is usually morally unacceptable (avoiding thorny philosophical questions about how it's sometimes justified) but that images do no direct harm and are therefore acceptable to me even though I find some of them disturbing and would personally prefer not to see them.
In the Unix -> Linux style, another OS to be ressurrected as a GPL-licensed reimplementation is VMS. Whilst the Open in OpenVMS doesn't refer to Open Source, the Free in FreeVMS really does mean Freedom.
The project's website is here:
http://www.freevms.net/
It appears to be based on Linux kernel code but implementing VMS-like behaviour on top of that. I've always heard that (if it wasn't for Unix), VMS would be *the* hacker OS. Plus Unix was popular because its code was pretty commonly available in the early days. VMS itself sounds awesome in a number of ways and I'm aware that it's still used in the Real World, although you rarely observe it directly.
FreeVMS are looking for developers, it would seem...
Well, I'd probably say yes - and no.
The fact that they're building a microkernel-based system helps. Mach presumably gives them features they need for that. But they *could* have just done what a lot of other microkernel-based systems have done and plonked a large monolithic Unix server on top. The impression that I'd had was that they instead designed things so that it was easy to replace individual components on a per-user basis.
I'm not especially familiar with Mach, other than some of the general principles. I suppose it's possible that even if a monolithic Unix server was providing most facilities it could still be possible to direct filesystem-related messages somewhere else? I don't really know.
The Hurd design was, as I understood it, really intended to make user-implemented filesystem servers be first class components (albeit with potentially reduced privileges), rather than just an alternate option.
Uh, did I manage to make sense, or have I missed the point?
Hurd got to a state where it was actually usable - there was a Debian distro of it, you could run X, you could run various applications, it was *real*. But that version was based on the Mach microkernel. Since then they went down the route of porting to the L4 microkernel (generally considered faster but I suspect YMMV depending on design & implementation of what you run on top of it). That work had some interesting ideas but last rumour I'd heard was that they'd stopped *that* port and that someone was working on a new microkernel that better fit their needs.
Hurd's design had nice features. For instance, it's fundamental to the design that users can replace OS components with their own, so custom userspace filesystems were easily supported. Linux gained this capability through FUSE but Hurd had it baked naturally into the design AFAIK.
I'd be quite interested in playing with Hurd but my main issue is that I don't perceive there being a very cohesive effort around it now, so I wouldn't know how to contribute or whether it would help at all. That might *just* be my perception, however the project has manifestly been "on the way" for a very long time.
The article also compared Zones to VServers and noted that the latter aren't in the Linux kernel and require patches. This is true but Linux contains OS-level virtualisation of it's own, which you can use via the LXC tools: http://lxc.sourceforge.net/
The VServers people expressed disinterest in merging their stuff into mainline. However, a combination of core Linux developers and OpenVZ developers have been working for some time on integrating full OS-level virtualisation into Linux, with the result that you can now run virtual machines on mainline Linux without any kernel patches. Not all the features of OpenVZ are supported (e.g. I think OpenVZ lets you do live migrations) but I'm not sure if Zones supports these either.
It's not surprising the author didn't know about the Linux container stuff, though - not much noise has been made about it. Presumably this is partly because the OpenVZ people haven't switched over to using it instead of their external patches yet. It is perhaps less mature / well-tested than Zones but nevertheless it is there, in the kernel, and you can just go ahead and use it if your distro built in support.
> OpenSolaris restores that warm fuzzy feeling from the Windows days where you get to waste hours (days? weeks?)
> installing 3rd party proprietary drivers and feeling like a computer expert instead of things "just working" out of the box.
An interesting thing I've noticed - Linux's not supporting a stable driver ABI is often cited as a reason for a lack of hardware support. Solaris has a stable driver ABI, FreeBSD has a stable driver ABI and yet I doubt that even if you install every 3rd party driver you can find they would support as many devices as Linux. A note on the fairness of this comparison: Linux has a larger userbase, so obviously there'll be more drivers for it. And yes, perhaps it's possible Linux would have even better driver support if it had a stable driver ABI.
The point I think is worth making is that the lack of a stable driver ABI gets cited as a reason why Linux sometimes has worse driver support than Windows. The theory being, AFAIK, that supporting a moving target is too much effort and is probably the thing that's turning off device manufacturers. I think looking at the other Unix-likes demonstrates that a stable driver ABI, whilst useful, is not necessarily the magic ingredient for widespread support that some people suggest. I'm sure it helps - but being able to continuously clean up the driver API (and making the relevant changes, for free, for all drivers in mainline) so that the drivers are easier to write also helps and doesn't require a massive change in the way Linux development is done.
Linux containers provide similar functionality to Solaris Zones: http://lxc.sourceforge.net/ They're a younger project but the support for them is in mainline Linux and you can do some pretty cool stuff with them. One thing that's nice (and I don't know if Zones can do this) is that you don't have to virtualise every aspect of a container, so for instance you can just isolate at the filesystem level if that's all you needed. Solaris Zones is capable of running apps for another OS within a Zone, using their system call compatibility layer. Linux has a system call compatibility layer but I don't know if it can run a complete other-OS userspace as Zones can (e.g. Zones can run CentOS or RHEL userland in a Zone, on top of the Solaris kernel).
Most everyone here is going to have heard of Btrfs but here it is again anyhow: http://btrfs.wiki.kernel.org/index.php/Main_Page It gives you similar stuff (checksumming, RAID-in-filesystem, writeable snapshots) to ZFS but again is a younger project. It's also in mainline Linux so you can play with it if you have a recent kernel (don't trust it with critical data, yet).
System Tap is one (of a number) DTrace-ish system for Linux: http://sourceware.org/systemtap/ I understand it'll run on basically any non-stoneage kernel but to get all of the juicy features you would (I *think*) need to patch your kernel. This is the only one of these projects for which full functionality appears not to be completely in mainline. Various distributions include it, so you can probably install a package and try it out (at least in a limited form, depending on your kernel).
A notable feature here is that none of these sound quite as mature as the Solaris equivalents. Not all of them constitute "copying", however - for instance, container-like solutions for Linux predate Solaris Zones by years (and BSD Jails, a similar concept, are almost certainly even older). I'm not sure on the dates of the others.
Oops, embarrassing, I always thought it was. Perhaps I just picked up the wrong idea somewhere - Google found me a whole raft of people who thought BeOS was a microkernel.
I'm actually a bit disappointed, in a way. I'm a fan of variety in operating systems and being a hybrid kernel (which I'd generally count as a different way of structuring what I'd call a monolithic kernel, though people seem to vary on their uses of these terms) is less different to the current popular OSes than a microkernel would have been :-(
Do you have a link for that FAQ btw, I didn't have much luck finding it on their newly revamped site. It's be really nice to see some more general architectural documentation about their kernel, which I should perhaps go hunting for. I grubbed around in their kernel code for a while recently but I just got an overview of what the APIs generally looked like and what filesystems were there.