Which is still antisocial enough that I would much rather kill experts-exchange from every search. Those results are almost never useful for the questions I'm asking, anyway.
That would allow a different kind of Google bombing. Remember the anti-DRM campaign which gave Spore all those low ratings? Seems likely that they could just kill EA from search results...
But even if it's just limited to a single user, it would be helpful to not have to put -site:expertsexchange.com in every search.
Well, actually, this system does solve quite a bit -- it establishes an interface in which plugin authors have to assume their code is completely unprivileged, and has access to nothing but a few safe APIs. It also forces those safe APIs to be thought through quite a bit.
At this point, nothing about the API and very little about the browsers implementing it has to change, if a Unix system were to suddenly support spawning new users as easily as it currently spawns new processes.
Or did you have a problem with the one-uid-per-object-tag approach?
Being in FF and having to go start/programs/Mozilla/Thunderbird takes just as long for them as opening Outlook Express, so why wouldn't they just open Outlook?
Because you've placed it in the same place they're used to looking for Outlook -- probably a QuickLaunch bar, or the Desktop -- and named it "Email".
But what I don't understand is if you are limiting extensions to reduce your dependence of Firefox and seem to like Konqueror so well, why are you still using FF?
Firebug, for work.
Also, the fact that Firefox seems to be the most compatible browser out there now. Some of these are genuine Konqueror bugs, but I suspect it's also because of things like Firebug -- since Firefox is now the most developer-friendly browser, and since it's F/OSS and free as in beer, there's a temptation to just make it work in Firefox and tell other people to just download that.
What does Konq do that FF don't?... You talk about customizing Konq,in what way?
One thing that frequently bothers me about Firefox -- can't get rid of the menu bar. In Konqueror (and in many other KDE apps), ctrl+m toggles it. It's also possible (at least in kde3, haven't tried since kde4) to create an OSX-like menu bar at the top of the screen, which all KDE apps will use -- but Firefox won't.
I know it uses the menu bar on OS X -- but on Linux/KDE, it doesn't.
There's also the stability -- Firefox is one process for your entire browser. If there's Flash, Javascript, or even a bug entirely in Firefox, even if it's buried deep in a tab in another window on another virtual desktop, it's going to affect you -- it's going to lag all Firefox windows, and when it crashes, it's going to crash all of them also.
Saving your session on crash is all well and good, but it's pretty embarrassing that they have to do that, and it doesn't always save you -- restoring a session on which one of the tabs crashes Firefox won't get you anywhere.
Konqueror is still one process per window (no matter how many tabs in that window), but at least a new window (which opens instantly) is a separate process. When one crashes, the other isn't gone. Especially useful if there's one page I know will be particularly buggy, or one that I need open no matter what.
There's also the fact -- both good and bad -- that Konqueror does very well with embedded kparts. Try opening a PDF in Firefox on Windows, and watch Adobe Reader crawl. Try the same thing in Konqueror, and it uses Okular. I haven't tried very hard, but I haven't found a way to get all of the same viewers in Firefox...
This also means it doesn't use anything Konqueror-specific for other things -- for example, opening an image is going to be Gwenview, with all the Gwenview settings and features, whether I did it from my desktop or from the Web.
The KIO integration is cool, too -- for example, I can type URLs like fish://user@host/some/path, browse around, open things in other KDE apps like Kate (editor) or Dragon Player, probably Amarok also. And all fish requires is that an ssh server is running on that host.
So, a lot of it is just better KDE integration -- Firefox has pretty much no KDE integration, so that's no contest.
Another fun part -- I suppose I could change this to point to Firefox, but right now, I can type alt+f2 for a "run" dialog. This is roughly like Firefox's "awesome bar", but for your OS -- I can type a command in there, just as though it were on the commandline. Or I can type the name of something from the menu, and see it autocomplete. Or I can type anything Konqueror understands -- URLs, or a search (gg:some keywords will Google for 'some keywords').
Aside from that, add in a few toys Firefox probably has as addons -- tap ctrl and there's a sort of rudimentary keyboard-based hyperlink navigation; shift+arrowkeys starts an autoscroll, or adjusts it faster/slower -- and most of the stuff I used to depend on in Firefox is just built in
So, what, you hack one user, you've hacked all users on the machine? Brilliant.
At least you've only got access to Flash for all the users on the machine -- better than TheRaven's suggestion of using 'nobody', in which case, you hack one user, you've got access to Flash, Java, and every other plugin, plus quite possibly a dozen other services written by similarly lazy programmers.
But you're right -- that's why I suggested a Unix user per currently-visible object tag. Each Flash ad as a separate process, under a separate user. But that would require a fair amount more work.
I can't see either sun or adobe wanting to port thier plugins to a managed code system.
I don't see why not -- both plugins already use managed code for their content.
A vm on a vm is going to get very messy and perform terriblly.
Not necessarily -- but more relevantly, when the vast majority of content out there is not directly manipulating the bytecode, it seems like a simple JIT compilation from the old VM to the new VM would solve that.
New code could be compiled directly for the new VM.
Consider, also, that C on LLVM is fast enough to run Quake.
and a new native code based plugin api isn't going to be significantly better than the existing one.
Why not?
For example: A new plugin API, based on native code, but which runs that code as an unprivileged user -- perhaps even in a hypervisor -- so that there are only a few, well-defined, well-tested interfaces for the plugin communicating with the world.
For 99% of what Flash does, simple audio/video is enough -- there's no reason it needs to be able to write to anywhere on the disk other than its own cookie-like storage, and there's certainly no reason any part of it needs to run unchecked in the same memory space as the rest of the browser.
It might not require a new API -- I'm not sure what the limits of the current one are -- but it would certainly require effort on the part of Flash developers.
The plugins people depend on are already written and are closed source so breaking them is not really an option
You'd think writing a brand-new plugin system would be, though. Keep the old one around, but for those who care about security (and don't need those old proprietary plugins), the new system will suffice. Once Flash and Java support the new system, watch the old system fade into disuse...
The current options are unsustainable -- native code is untrusted (and can at least crash the browser unintentionally). Javascript in a webpage is too limited -- the language is fine (contrary to popular belief), but the APIs are lacking in a few key areas. And the only options in between are either browser-specific, or based on plugins -- and the only plugins I know of that do this are Google Gears (ridiculously small adoption), Java (bad reputation and most implementations out of date), and Flash (proprietary).
Installing apps requires root access, running them does not.
This combination is important -- it means that you're only root for those short periods of time in which you're installing software, but not while it's running. It means that for someone to accidentally wipe out your entire system through shoddy programming, say, it would have to be a shoddy installer, not a shoddy app -- and since the installers are mostly standard (package managers, and even most make install scripts are standard), this is a lot harder to do by accident.
Once installed, most things don't require root.
This means that, with the better structured programs -- lots of system daemons are built this way -- they run as users which only have access to what they need. If cups decides to go on a rampage, all it can do is delete your print queues. It can't even uninstall cups, let alone other programs.
With most user-facing programs, like browsers, this means that no matter how many crappy Firefox extensions you install, you won't affect any other users on the system -- because no Firefox extension, by accident or on purpose, can modify the root-owned system files, where Firefox itself is installed.
This is less perfect, though, especially for a single-user machine -- after all, if Firefox decides to go on a rampage (much more likely than cups, if you think about the amount of code and responsibility each has), it will wipe out my home directory. On a single-user machine, that means all my data is gone. I suppose I could've backed it all up as another user...
But it does have one nice side effect -- at least I know that if I backup/home entirely, I can simply restore that, and the rest of the system probably hasn't been touched. In fact, unrelated to security, I find Linux much easier to back up than Windows, in the places where it counts (anyone can take a disk image...)
Just in case anyone was going to interpret this literally:
Ideally, most of these plugins should be setuid as nobody
No, no, a thousand times no!
I suppose "nobody" was a clever concept, whenever it was invented. After all, with only one or two daemons using it, and with so few permissions, that was a reasonably smart move.
These days, nobody is anything but -- since all the more lazily-developed (or lazily-admined) apps just use nobody for their unprivileged user, that means one app's nobody process can easily screw with another app's nobody process.
The right solution would be to either run all plugins in some sort of completely managed, protected VM -- kind of like we do for Javascript -- or create a new Unix user per plugin.
In fact, checking on my system, user ids are four bytes. That is, over four billion possible user ids. Granted,/etc/passwd is woefully ill-equipped to handle that many users -- but given a system which could, there's no reason I know of not to create a new Unix user per currently-visible object tag.
But at the very least, I beg you, create a flash-plugin user, and a java-plugin user, etc. Please, please don't just use nobody. It's like people who programmatically look for a tag called 'foo:bar', instead of bothering to learn how XML namespaces actually work -- you're so close to understanding it, don't stop now!
In KDE4, that seems to happen a lot less -- on top of which, much lower CPU usage with applets, and when Konqueror crashes, at least it's just a single window -- and all its tabs, unfortunately, but better than all windows as in Firefox.
I have Seamonkey for the older folks who like to download their email
Out of curiosity, what's the advantage of Seamonkey for that purpose, versus a combination of Firefox and Thunderbird?
I actually have a grand total of four extensions right now -- Firebug, Firecookie, Greasemonkey, and the Ubuntu Firefox Pack. Of those, Greasemonkey is off almost all the time. I actually avoid installing more, both to avoid making the browser slow/buggy/etc, and to reduce my dependence on Firefox, at least as a user.
I can customize Firefox, but not quite as much as I'd like, and there are some things Konqueror just seems to do better, especially on Kubuntu.
We might start thinking a little more about what is the highest bandwidth form of gestural expression, and stop worrying about conserving motion!
Well, let's look at one of the higher-bandwidth forms of expression -- typing. How would you type -- even assuming you were limited to a single language -- with a gestural interface? The only way I can think of is speaking, which at least feels like it uses less motion than typing!
The reason we conserve motion is that it's faster -- and for some interfaces, speed is everything. Not all, certainly, or the mouse would never have been invented -- but the mouse didn't replace the keyboard, and I doubt this will, either -- it might not even replace the mouse.
Not that we shouldn't pursue it, but it needs to have some real benefits, probably in specific applications.
I think my ideal mental interface would be the control of a body that doesn't get tired.
Right -- which would probably be an entirely artificial or virtual body.
So, take your neural interface, imagine every passing thought thrown into some sort of sandbox. Then, when it's reasonably close to done, use a more "physical" means to freeze it, verify it, and do whatever else with it.
So, stream-of-consciousness (literally) email composing, but a physical action required to send. Best of both worlds.
Or, failing the virtual body, stream-of-consciousness followed by any interface we have today. Keyboard input to an email limited to the text field in question, suspended when any meta-keys (ctrl, alt, etc) are pressed, and an actual keyboard/mouse action required to send.
how much force/pressure/tolerance does a gesture need to actually trigger...and how much visual feedback to give during the gesture.
Well, that's a bit like the confirmation "passing thought" problem all over again.
Again, a virtual body solves this problem -- rather than waving your hands in the air, you're dealing with what looks and feels like some sort of physical interface. That means simple depth perception, probably some tactile feedback -- a certain amount of pressure required to actually press the button.
Or, again, a physcial interface to compliment it.
Double-clicks are kind of a cool thing and we've gotten used to it.
I think right-clicking is far more useful than double-clicking.
More relevantly -- consider the most common use: Icons in a folder, probably on a desktop. Single-click selects one, double-click opens it. When was the last time you needed to select exactly one file to perform an action on it? Especially one which couldn't be performed by click+drag or right-click?
And if you're selecting multiple items, click+dragging a box around them is a much more convenient interface.
The only thing double-clicking is useful for is people who don't know about the above -- but those people would never have a reason to select a file without opening it. Worse, it trains these people that some things need to be double-clicked on -- many apply that paradigm to other things, like hyperlinks and buttons, because hey, if they click twice, at least they know it got the message. Worse are the people who single-click everything, then, if it doesn't work, double-click it to be sure -- same with opening something from the desktop.
Of all the GUI paradigms we've grown to love and hate, that's probably the one that annoys me the most.
But, your point is well taken:
Someone has to go through the trial and error of solving the 3D counterparts of these problems.
The only question is, again, whether or not this 3D interface is the best one.
Buy yourself a decent workstation. No need to go overboard, anything relatively recent will work.
No need for any fancy VMs, just pick an OS you're comfortable with -- preferably something Unix-y (OS X or Ubuntu) -- Windows will work, too, but it'll be more frustrating unless you're developing.NET.
In my case, I develop mostly with Ruby -- not all Rails, but pretty much all frameworks follow the same pattern of embedding a webserver in the app. So there's no need for a separate server -- just fire up the app and open a browser to http://localhost:3000/
Need to test two clients? Open two browsers! Problem solved.
The time to worry about anything more than one workstation is when you've actually got an app ready to go. But if you need more testing than is available on that one workstation, you need to talk to your clients anyway, and figure out how they intend to deploy it -- or come up with something yourself.
The only other reason to do so is if you're building something more complex than the typical web/rdbms model that everyone seems to be doing. Even here, a lot can be done with a single machine -- run two Erlang nodes, for example -- before you have to start thinking about VMs.
And by the time that's not enough -- when you're actually considering simulating a small network -- you're probably at the point where you'll have to talk to some real live clients and find out how the app will actually be run. If you get to make that call, I'd suggest Amazon EC2 (and remember to shut your nodes down at the end of the day) -- but keep it modular; Amazon is lagging behind Moore's Law in pricing, which means better alternatives may surface, which means you want to thoroughly encapsulate anything Amazon-specific.
What clear distinction can I make that best approximates the fuzzy distinction I have in my head?
See, I wasn't trying to show that his distinctions were too fuzzy for law -- they're too fuzzy for me to see clearly what he means in my head.
I can see that there is value to having all creative works be free. Why should a software hobbyist have less freedom than a music hobbyist? A remix may contain no executable code, and may be of no "practical" use, but there is certainly value in encouraging remixing.
That's the simple answer to Stallman's distinctions -- there is no distinction. Either we should demand that everything be free, or we should allow that it's up to the creator -- but we shouldn't tie that choice to something as vague as practicality.
As an example: Lasers were once thought to be a solution in search of a problem. The only way to know whether something is practical is to try to use it for something -- and by the time it's found to be practical, it may be too late for it to be free.
But if everything is free -- and I understand that, in this context, "free" means "libre" -- there is still the problem of who gets paid, and how. If we agree that copies of creative works should cost money, the "who" becomes especially tricky. If only the act of creating something should cost money, one of the major incentives to be creative goes away.
What I'm talking about is something that tells the END USER, if the file is free or not, and a service that backs it up would be WORTH PAYING FOR.
If that's all you're after, it seems like the simple solution is to seek out forums where free music (and other media) is distributed.
For example: Revision 3. Yes, they use BitTorrent -- but if you want to be sure it's legit, you go to rev3's website and get the torrents from there.
No pay service needed -- just don't be trolling the Pirate Bay, or older P2P systems like Kazaa and Gnutella, and you're fine.
But what about the grey-area bands that nobody knows? What about that techno band who has a bootleg on the internet, that everyone loves and is downloading?
If the techno band wants everyone to download it, there are ways they can get that out there. In fact, I work for a company which (among other things) makes that process easier for those artists.
If the techno band doesn't have the right to release it for free, that's a problem with their contract, not with the distribution system.
I have an idea. The RIAA and MPAA should be forced to release an XML file on P2P networks that lists their copyright materials, so that we can choose to exclude them from our libraries if they happen to get on there.
XML? Really?
Just because: Why not JSON? Or YAML? Or binary-XML, like MKV does? XML doesn't automatically mean open format, nor do open formats necessarily have to be XML.
But more realistically -- XML is far too small for any P2P network to be wasting its time with. Someone would ultimately have to host it.
There's also the problem of reliably identifying a bit of media, regardless of things like container and encoding. A simple md5 won't work.
And that's just the technical aspect...
Why don't they do that? Oh right... because they make millions suing people.
As conspiracy theories go, that one's pretty weak. We're talking about lawsuits against teenage girls, grandmothers, and dead people. Do most of their targets even have enough money in their savings to cover the legal fees alone?
How about: They don't do it because it would require someone to develop, distribute, and maintain a spec. They can't even agree on a single DRM format to shove down our throats; what makes you think this would be any different?
It also would require adoption to work. So, why should I adopt it? It's certainly not a guarantee of anything -- the MPAA and RIAA are certainly not the only copyright holders, and without some bizarre new law, there's nothing forcing even them to keep that list updated and complete.
So, assuming it was accurate, such a list would only tell me which media in my library is not OK. It couldn't tell me which is legal. Pragmatically speaking, since I can never really know which parts are legit, I may as well assume all of it might be found to be illegal, and encrypt the whole drive.
But let's say it works -- they'd still be suing people, because not everyone would know about the new format, and those who did might not care. They can always claim in court that they didn't know about it.
Actually, my school's network requires naught but that you register your computer.
Indeed -- and if the only service you require is Internet access, that's how it should be.
I'm talking about things like using the school printers, school computer labs (remotely), school email system, etc. Some of these can be provided as web services -- webmail, IPP for printing...
I would guess that by the time you're talking about having to install SSH or Kerberos (for something which legitimately requires these things), a VPN client isn't too much to ask.
In fact, at that point, the only practical difference for the student is that when their Internet access doesn't work, they call their ISP, not the school.
Problem there is, you completely lose your own brand recognition.
Dell selling Ubuntu is a hell of a lot more powerful than, say, Foss Notebooks (a Dell spinoff) selling Ubuntu.
Or am I misunderstanding -- could they keep the name, and be a separate company? Wouldn't that make it really easy for Microsoft to see through the ploy?
This pretty much is net neutrality -- rather than throttling some parts of service, if they don't like you, they cut you off wholesale.
It's a good point, though -- I think it's more akin to actual vigilante justice. Murder is illegal, and we have due process for a reason, but there are certain people I wouldn't mind seeing shot.
Anyone helping the spammers are just as guilty as the spammers.
That's Godwinbait.
I would say, the losses are acceptable. Internet users shouldn't be expected to investigate exactly who else their ISP is doing business with, so they are innocent -- but ultimately, it's just an inconvenience, it's not the end of the world, and it looks as though most of the people hit by this were, in fact, spammers.
The end result is either the death of an ISP (so everyone switches to another), or the reform of an ISP -- they kick all the spammers off, try to retain their legitimate customers, and get re-peered.
But none of this implies there's any blame whatsoever in unknowingly using the same ISP as spammers. If you want to blame someone, blame the people who actually buy what the spammers are spamming about.
Slashdot Mirror
Which is still antisocial enough that I would much rather kill experts-exchange from every search. Those results are almost never useful for the questions I'm asking, anyway.
That would allow a different kind of Google bombing. Remember the anti-DRM campaign which gave Spore all those low ratings? Seems likely that they could just kill EA from search results...
But even if it's just limited to a single user, it would be helpful to not have to put -site:expertsexchange.com in every search.
Well, actually, this system does solve quite a bit -- it establishes an interface in which plugin authors have to assume their code is completely unprivileged, and has access to nothing but a few safe APIs. It also forces those safe APIs to be thought through quite a bit.
At this point, nothing about the API and very little about the browsers implementing it has to change, if a Unix system were to suddenly support spawning new users as easily as it currently spawns new processes.
Or did you have a problem with the one-uid-per-object-tag approach?
Being in FF and having to go start/programs/Mozilla/Thunderbird takes just as long for them as opening Outlook Express, so why wouldn't they just open Outlook?
Because you've placed it in the same place they're used to looking for Outlook -- probably a QuickLaunch bar, or the Desktop -- and named it "Email".
But what I don't understand is if you are limiting extensions to reduce your dependence of Firefox and seem to like Konqueror so well, why are you still using FF?
Firebug, for work.
Also, the fact that Firefox seems to be the most compatible browser out there now. Some of these are genuine Konqueror bugs, but I suspect it's also because of things like Firebug -- since Firefox is now the most developer-friendly browser, and since it's F/OSS and free as in beer, there's a temptation to just make it work in Firefox and tell other people to just download that.
What does Konq do that FF don't?... You talk about customizing Konq,in what way?
One thing that frequently bothers me about Firefox -- can't get rid of the menu bar. In Konqueror (and in many other KDE apps), ctrl+m toggles it. It's also possible (at least in kde3, haven't tried since kde4) to create an OSX-like menu bar at the top of the screen, which all KDE apps will use -- but Firefox won't.
I know it uses the menu bar on OS X -- but on Linux/KDE, it doesn't.
There's also the stability -- Firefox is one process for your entire browser. If there's Flash, Javascript, or even a bug entirely in Firefox, even if it's buried deep in a tab in another window on another virtual desktop, it's going to affect you -- it's going to lag all Firefox windows, and when it crashes, it's going to crash all of them also.
Saving your session on crash is all well and good, but it's pretty embarrassing that they have to do that, and it doesn't always save you -- restoring a session on which one of the tabs crashes Firefox won't get you anywhere.
Konqueror is still one process per window (no matter how many tabs in that window), but at least a new window (which opens instantly) is a separate process. When one crashes, the other isn't gone. Especially useful if there's one page I know will be particularly buggy, or one that I need open no matter what.
There's also the fact -- both good and bad -- that Konqueror does very well with embedded kparts. Try opening a PDF in Firefox on Windows, and watch Adobe Reader crawl. Try the same thing in Konqueror, and it uses Okular. I haven't tried very hard, but I haven't found a way to get all of the same viewers in Firefox...
This also means it doesn't use anything Konqueror-specific for other things -- for example, opening an image is going to be Gwenview, with all the Gwenview settings and features, whether I did it from my desktop or from the Web.
The KIO integration is cool, too -- for example, I can type URLs like fish://user@host/some/path, browse around, open things in other KDE apps like Kate (editor) or Dragon Player, probably Amarok also. And all fish requires is that an ssh server is running on that host.
So, a lot of it is just better KDE integration -- Firefox has pretty much no KDE integration, so that's no contest.
Another fun part -- I suppose I could change this to point to Firefox, but right now, I can type alt+f2 for a "run" dialog. This is roughly like Firefox's "awesome bar", but for your OS -- I can type a command in there, just as though it were on the commandline. Or I can type the name of something from the menu, and see it autocomplete. Or I can type anything Konqueror understands -- URLs, or a search (gg:some keywords will Google for 'some keywords').
Aside from that, add in a few toys Firefox probably has as addons -- tap ctrl and there's a sort of rudimentary keyboard-based hyperlink navigation; shift+arrowkeys starts an autoscroll, or adjusts it faster/slower -- and most of the stuff I used to depend on in Firefox is just built in
So, what, you hack one user, you've hacked all users on the machine? Brilliant.
At least you've only got access to Flash for all the users on the machine -- better than TheRaven's suggestion of using 'nobody', in which case, you hack one user, you've got access to Flash, Java, and every other plugin, plus quite possibly a dozen other services written by similarly lazy programmers.
But you're right -- that's why I suggested a Unix user per currently-visible object tag. Each Flash ad as a separate process, under a separate user. But that would require a fair amount more work.
I can't see either sun or adobe wanting to port thier plugins to a managed code system.
I don't see why not -- both plugins already use managed code for their content.
A vm on a vm is going to get very messy and perform terriblly.
Not necessarily -- but more relevantly, when the vast majority of content out there is not directly manipulating the bytecode, it seems like a simple JIT compilation from the old VM to the new VM would solve that.
New code could be compiled directly for the new VM.
Consider, also, that C on LLVM is fast enough to run Quake.
and a new native code based plugin api isn't going to be significantly better than the existing one.
Why not?
For example: A new plugin API, based on native code, but which runs that code as an unprivileged user -- perhaps even in a hypervisor -- so that there are only a few, well-defined, well-tested interfaces for the plugin communicating with the world.
For 99% of what Flash does, simple audio/video is enough -- there's no reason it needs to be able to write to anywhere on the disk other than its own cookie-like storage, and there's certainly no reason any part of it needs to run unchecked in the same memory space as the rest of the browser.
It might not require a new API -- I'm not sure what the limits of the current one are -- but it would certainly require effort on the part of Flash developers.
The plugins people depend on are already written and are closed source so breaking them is not really an option
You'd think writing a brand-new plugin system would be, though. Keep the old one around, but for those who care about security (and don't need those old proprietary plugins), the new system will suffice. Once Flash and Java support the new system, watch the old system fade into disuse...
The current options are unsustainable -- native code is untrusted (and can at least crash the browser unintentionally). Javascript in a webpage is too limited -- the language is fine (contrary to popular belief), but the APIs are lacking in a few key areas. And the only options in between are either browser-specific, or based on plugins -- and the only plugins I know of that do this are Google Gears (ridiculously small adoption), Java (bad reputation and most implementations out of date), and Flash (proprietary).
Installing apps requires root access, running them does not.
This combination is important -- it means that you're only root for those short periods of time in which you're installing software, but not while it's running. It means that for someone to accidentally wipe out your entire system through shoddy programming, say, it would have to be a shoddy installer, not a shoddy app -- and since the installers are mostly standard (package managers, and even most make install scripts are standard), this is a lot harder to do by accident.
Once installed, most things don't require root.
This means that, with the better structured programs -- lots of system daemons are built this way -- they run as users which only have access to what they need. If cups decides to go on a rampage, all it can do is delete your print queues. It can't even uninstall cups, let alone other programs.
With most user-facing programs, like browsers, this means that no matter how many crappy Firefox extensions you install, you won't affect any other users on the system -- because no Firefox extension, by accident or on purpose, can modify the root-owned system files, where Firefox itself is installed.
This is less perfect, though, especially for a single-user machine -- after all, if Firefox decides to go on a rampage (much more likely than cups, if you think about the amount of code and responsibility each has), it will wipe out my home directory. On a single-user machine, that means all my data is gone. I suppose I could've backed it all up as another user...
But it does have one nice side effect -- at least I know that if I backup /home entirely, I can simply restore that, and the rest of the system probably hasn't been touched. In fact, unrelated to security, I find Linux much easier to back up than Windows, in the places where it counts (anyone can take a disk image...)
Just in case anyone was going to interpret this literally:
Ideally, most of these plugins should be setuid as nobody
No, no, a thousand times no!
I suppose "nobody" was a clever concept, whenever it was invented. After all, with only one or two daemons using it, and with so few permissions, that was a reasonably smart move.
These days, nobody is anything but -- since all the more lazily-developed (or lazily-admined) apps just use nobody for their unprivileged user, that means one app's nobody process can easily screw with another app's nobody process.
The right solution would be to either run all plugins in some sort of completely managed, protected VM -- kind of like we do for Javascript -- or create a new Unix user per plugin.
In fact, checking on my system, user ids are four bytes. That is, over four billion possible user ids. Granted, /etc/passwd is woefully ill-equipped to handle that many users -- but given a system which could, there's no reason I know of not to create a new Unix user per currently-visible object tag.
But at the very least, I beg you, create a flash-plugin user, and a java-plugin user, etc. Please, please don't just use nobody. It's like people who programmatically look for a tag called 'foo:bar', instead of bothering to learn how XML namespaces actually work -- you're so close to understanding it, don't stop now!
In KDE4, that seems to happen a lot less -- on top of which, much lower CPU usage with applets, and when Konqueror crashes, at least it's just a single window -- and all its tabs, unfortunately, but better than all windows as in Firefox.
I have Seamonkey for the older folks who like to download their email
Out of curiosity, what's the advantage of Seamonkey for that purpose, versus a combination of Firefox and Thunderbird?
I actually have a grand total of four extensions right now -- Firebug, Firecookie, Greasemonkey, and the Ubuntu Firefox Pack. Of those, Greasemonkey is off almost all the time. I actually avoid installing more, both to avoid making the browser slow/buggy/etc, and to reduce my dependence on Firefox, at least as a user.
I can customize Firefox, but not quite as much as I'd like, and there are some things Konqueror just seems to do better, especially on Kubuntu.
We might start thinking a little more about what is the highest bandwidth form of gestural expression, and stop worrying about conserving motion!
Well, let's look at one of the higher-bandwidth forms of expression -- typing. How would you type -- even assuming you were limited to a single language -- with a gestural interface? The only way I can think of is speaking, which at least feels like it uses less motion than typing!
The reason we conserve motion is that it's faster -- and for some interfaces, speed is everything. Not all, certainly, or the mouse would never have been invented -- but the mouse didn't replace the keyboard, and I doubt this will, either -- it might not even replace the mouse.
Not that we shouldn't pursue it, but it needs to have some real benefits, probably in specific applications.
I think my ideal mental interface would be the control of a body that doesn't get tired.
Right -- which would probably be an entirely artificial or virtual body.
So, take your neural interface, imagine every passing thought thrown into some sort of sandbox. Then, when it's reasonably close to done, use a more "physical" means to freeze it, verify it, and do whatever else with it.
So, stream-of-consciousness (literally) email composing, but a physical action required to send. Best of both worlds.
Or, failing the virtual body, stream-of-consciousness followed by any interface we have today. Keyboard input to an email limited to the text field in question, suspended when any meta-keys (ctrl, alt, etc) are pressed, and an actual keyboard/mouse action required to send.
how much force/pressure/tolerance does a gesture need to actually trigger...and how much visual feedback to give during the gesture.
Well, that's a bit like the confirmation "passing thought" problem all over again.
Again, a virtual body solves this problem -- rather than waving your hands in the air, you're dealing with what looks and feels like some sort of physical interface. That means simple depth perception, probably some tactile feedback -- a certain amount of pressure required to actually press the button.
Or, again, a physcial interface to compliment it.
Double-clicks are kind of a cool thing and we've gotten used to it.
I think right-clicking is far more useful than double-clicking.
More relevantly -- consider the most common use: Icons in a folder, probably on a desktop. Single-click selects one, double-click opens it. When was the last time you needed to select exactly one file to perform an action on it? Especially one which couldn't be performed by click+drag or right-click?
And if you're selecting multiple items, click+dragging a box around them is a much more convenient interface.
The only thing double-clicking is useful for is people who don't know about the above -- but those people would never have a reason to select a file without opening it. Worse, it trains these people that some things need to be double-clicked on -- many apply that paradigm to other things, like hyperlinks and buttons, because hey, if they click twice, at least they know it got the message. Worse are the people who single-click everything, then, if it doesn't work, double-click it to be sure -- same with opening something from the desktop.
Of all the GUI paradigms we've grown to love and hate, that's probably the one that annoys me the most.
But, your point is well taken:
Someone has to go through the trial and error of solving the 3D counterparts of these problems.
The only question is, again, whether or not this 3D interface is the best one.
This doesn't help address the point at hand -- which is a valid point -- but KDE4 does have an Expose clone built-in.
Buy yourself a decent workstation. No need to go overboard, anything relatively recent will work.
No need for any fancy VMs, just pick an OS you're comfortable with -- preferably something Unix-y (OS X or Ubuntu) -- Windows will work, too, but it'll be more frustrating unless you're developing .NET.
In my case, I develop mostly with Ruby -- not all Rails, but pretty much all frameworks follow the same pattern of embedding a webserver in the app. So there's no need for a separate server -- just fire up the app and open a browser to http://localhost:3000/
Need to test two clients? Open two browsers! Problem solved.
The time to worry about anything more than one workstation is when you've actually got an app ready to go. But if you need more testing than is available on that one workstation, you need to talk to your clients anyway, and figure out how they intend to deploy it -- or come up with something yourself.
The only other reason to do so is if you're building something more complex than the typical web/rdbms model that everyone seems to be doing. Even here, a lot can be done with a single machine -- run two Erlang nodes, for example -- before you have to start thinking about VMs.
And by the time that's not enough -- when you're actually considering simulating a small network -- you're probably at the point where you'll have to talk to some real live clients and find out how the app will actually be run. If you get to make that call, I'd suggest Amazon EC2 (and remember to shut your nodes down at the end of the day) -- but keep it modular; Amazon is lagging behind Moore's Law in pricing, which means better alternatives may surface, which means you want to thoroughly encapsulate anything Amazon-specific.
Well said... I thought this comic illustrated it well, also.
Given that there are alternate left-hand-only and right-hand-only variants of Dvorak, you can technically type any word entirely with either hand.
that's not in any way due to Sun's generosity.
I suspect having the source code to the JDK helped -- and that was Sun's generosity.
I wonder if it would've taken so many years if Flash had been open?
Mine running Ubuntu certainly seems to be.
What clear distinction can I make that best approximates the fuzzy distinction I have in my head?
See, I wasn't trying to show that his distinctions were too fuzzy for law -- they're too fuzzy for me to see clearly what he means in my head.
I can see that there is value to having all creative works be free. Why should a software hobbyist have less freedom than a music hobbyist? A remix may contain no executable code, and may be of no "practical" use, but there is certainly value in encouraging remixing.
That's the simple answer to Stallman's distinctions -- there is no distinction. Either we should demand that everything be free, or we should allow that it's up to the creator -- but we shouldn't tie that choice to something as vague as practicality.
As an example: Lasers were once thought to be a solution in search of a problem. The only way to know whether something is practical is to try to use it for something -- and by the time it's found to be practical, it may be too late for it to be free.
But if everything is free -- and I understand that, in this context, "free" means "libre" -- there is still the problem of who gets paid, and how. If we agree that copies of creative works should cost money, the "who" becomes especially tricky. If only the act of creating something should cost money, one of the major incentives to be creative goes away.
What I'm talking about is something that tells the END USER, if the file is free or not, and a service that backs it up would be WORTH PAYING FOR.
If that's all you're after, it seems like the simple solution is to seek out forums where free music (and other media) is distributed.
For example: Revision 3. Yes, they use BitTorrent -- but if you want to be sure it's legit, you go to rev3's website and get the torrents from there.
No pay service needed -- just don't be trolling the Pirate Bay, or older P2P systems like Kazaa and Gnutella, and you're fine.
But what about the grey-area bands that nobody knows? What about that techno band who has a bootleg on the internet, that everyone loves and is downloading?
If the techno band wants everyone to download it, there are ways they can get that out there. In fact, I work for a company which (among other things) makes that process easier for those artists.
If the techno band doesn't have the right to release it for free, that's a problem with their contract, not with the distribution system.
I have an idea. The RIAA and MPAA should be forced to release an XML file on P2P networks that lists their copyright materials, so that we can choose to exclude them from our libraries if they happen to get on there.
XML? Really?
Just because: Why not JSON? Or YAML? Or binary-XML, like MKV does? XML doesn't automatically mean open format, nor do open formats necessarily have to be XML.
But more realistically -- XML is far too small for any P2P network to be wasting its time with. Someone would ultimately have to host it.
There's also the problem of reliably identifying a bit of media, regardless of things like container and encoding. A simple md5 won't work.
And that's just the technical aspect...
Why don't they do that? Oh right... because they make millions suing people.
As conspiracy theories go, that one's pretty weak. We're talking about lawsuits against teenage girls, grandmothers, and dead people. Do most of their targets even have enough money in their savings to cover the legal fees alone?
How about: They don't do it because it would require someone to develop, distribute, and maintain a spec. They can't even agree on a single DRM format to shove down our throats; what makes you think this would be any different?
It also would require adoption to work. So, why should I adopt it? It's certainly not a guarantee of anything -- the MPAA and RIAA are certainly not the only copyright holders, and without some bizarre new law, there's nothing forcing even them to keep that list updated and complete.
So, assuming it was accurate, such a list would only tell me which media in my library is not OK. It couldn't tell me which is legal. Pragmatically speaking, since I can never really know which parts are legit, I may as well assume all of it might be found to be illegal, and encrypt the whole drive.
But let's say it works -- they'd still be suing people, because not everyone would know about the new format, and those who did might not care. They can always claim in court that they didn't know about it.
Actually, my school's network requires naught but that you register your computer.
Indeed -- and if the only service you require is Internet access, that's how it should be.
I'm talking about things like using the school printers, school computer labs (remotely), school email system, etc. Some of these can be provided as web services -- webmail, IPP for printing...
I would guess that by the time you're talking about having to install SSH or Kerberos (for something which legitimately requires these things), a VPN client isn't too much to ask.
In fact, at that point, the only practical difference for the student is that when their Internet access doesn't work, they call their ISP, not the school.
Problem there is, you completely lose your own brand recognition.
Dell selling Ubuntu is a hell of a lot more powerful than, say, Foss Notebooks (a Dell spinoff) selling Ubuntu.
Or am I misunderstanding -- could they keep the name, and be a separate company? Wouldn't that make it really easy for Microsoft to see through the ploy?
This pretty much is net neutrality -- rather than throttling some parts of service, if they don't like you, they cut you off wholesale.
It's a good point, though -- I think it's more akin to actual vigilante justice. Murder is illegal, and we have due process for a reason, but there are certain people I wouldn't mind seeing shot.
Anyone helping the spammers are just as guilty as the spammers.
That's Godwinbait.
I would say, the losses are acceptable. Internet users shouldn't be expected to investigate exactly who else their ISP is doing business with, so they are innocent -- but ultimately, it's just an inconvenience, it's not the end of the world, and it looks as though most of the people hit by this were, in fact, spammers.
The end result is either the death of an ISP (so everyone switches to another), or the reform of an ISP -- they kick all the spammers off, try to retain their legitimate customers, and get re-peered.
But none of this implies there's any blame whatsoever in unknowingly using the same ISP as spammers. If you want to blame someone, blame the people who actually buy what the spammers are spamming about.
I would also tick this one:
(X) Killing them that way is not slow and painful enough