but I also have to enter a password. That is a good thing
As far as I know, anything on the system can create something that looks like a valid UAC box, dim the screen, etc. Certainly, I'd imagine this to be the case on OS X or Linux (with sudo or whatever). So, with just a simple yes/no dialog (or allow/deny), you can click "yes" on anything, but it's only a problem if you click "yes" to an actual UAC box without reading it. They can spoof a passwordless UAC box all they want, but if you don't click "yes", it won't do anything.
However, if they popup something that looks identical to a UAC box, but captures your password, well, they now have your password. Certainly this is a problem on Linux/OSX, as su (and sudo) don't really attempt to go farther than making sure they're reading directly from a terminal -- usually a pseudoterminal, meaning it's just a bit more annoying to find a way to pipe a password into sudo.
So, without doing the research, my question is:
Do you have to hit ctrl+alt+del to enter that password? Because generally, ctrl+alt+del is not interceptable, and if it's not expecting a password, it'll take you to another screen, and you'll know the box was fake.
Is there a way to authenticate without Windows forcing it to be a real, physical keyboard/mouse? Seems to me the attacker could always rdesktop to localhost or something like that, but if the only place Windows accepts your password from is the keyboard (a major PITA for things like VNC, for those who prefer it to rdesktop, or if rdesktop is broken), then I suppose an attacker knowing your Windows password isn't really a security risk.
Reading these articles and the comments here, it would seem that wine has a much better chance of being efficient than cygwin ever will, simply because UNIX APIs tend to be sensibly lower level. So, cygwin is a bit like trying to implement, say, C or C++ on top of C#. You could do it, but it would be much more efficient to build C# on top of C or C++, and, in fact, we do (Mono is written in C++, if I remember right).
As I understand it, Linux processes are lightweight enough that modern pthreads on Linux builds on top of fork/exec. Or something like that -- one is a wrapper for the other, I think.
In any case, reading through your suggestions, the only real difference is that if you're writing in C (and thus vulnerable to buffer overflows), segfaulting a process won't bring down the entire app. One other difference is that fork/exec would tend to be easy to make distributed, as most of your communication would be in pipes. However, both of these ultimately come down to how the app is written, not what language or API you're using.
So, the only real difference will be performance implications. On Windows, it's MUCH cheaper to spawn a thread than a process, and there is no fork, so on Windows, monolithic monstrosities are the only viable way to go.
Problem: What if one significant reason a Linux machine is better than a Windows machine is the lack of malware? Thus, a fresh (non-OEM) Windows install will get loaded with malware infinitely faster than a fresh Linux install, as the Linux install will never get hit with malware.
Now, if you install malware from the beginning (with crapplets), Linux completely loses that advantage. Granted, it may still be an improvement, but it becomes one hell of a baby step. It's hardly a free/open platform if it comes with BonziBuddy Unix Edition. (Yes, I made that up -- I'll insult BonziBuddy till they sue me, and then I'll switch over to insulting Gator or something.)
I will buy a Dell for my next laptop, if it comes preloaded with a decent Linux distro and without a bunch of crap. (I will not pay for the crap.)
I'll even buy it if it isn't a distro I like.
However' if you really want to blow us away, Dell, give us a few of the configurable install options available via the website -- preferably without Flash or excessive JavaScript required. Maybe a web-based debian-installer? Because I'd like to be able to choose filesystem, partitioning scheme, and base distro (maybe from a limited selection -- hell, just Ubuntu and Fedora would probably satisfy most people who would care about pre-installed). I want to be able to choose these not because I am such a nerd, but because they aren't easy to change after an install -- which is probably why Dell lets you choose FAT32 or NTFS when ordering an XP computer.
But I fear the coming of the Linux Crapplets. I fear what happens when AOL starts placing icons on my Gnome desktop.
And I pray that Dell does the right thing and drops the crapplets -- insist that they stop paying per machine sold and start just paying for Windows licenses sold, and use the money saved there to avoid preloading random crap other than the OS.
How many people here know about Blizzard shutting down Free Software competition with phony copyright claims and yet carry on using WoW?
See, Blizzard does get a bit of credit for actually working with Cedega to fix World of Warcraft problems. None of the other companies you mentioned have done anything to improve their karma.
How many geeks despise Microsoft's abusive lawbreaking and went out and bought an XBox?
And this is what bothers me about the corporation, specifically the conglomerate. I like Bungie, and I like the Halo series, but I hate Microsoft.
So, Halo and Halo 2 was worth buying an Xbox for, and Halo 3 will be worth buying a 360 for, but neither is worth selling my soul for. So I borrow them from friends.
The fickle, greedy nature of Western consumerism causes this problem...
There's a more fundamental problem, maybe the same cause: Lack of competition and standards, and huge organizations, makes it very hard to separate the good from the bad. I can't buy a Halo game without supporting Microsoft indirectly by paying Bungie, and directly by buying an Xbox (because they mostly aren't available on a non-Microsoft platform).
If a developer already has to implement their own update mechanism to insure this for new versions and the initial registration and host their own "repository" for the software, why shouldn't they just roll their own service entirely?
If I already have to implement my own login mechanism and host my own "website" of pages, why shouldn't I just roll my own HTTP server entirely?
Here's hoping they find a way to save time by using the existing package managers. I know I would. Dependencies alone is a pretty big deal -- for instance, suppose you ship a product written in python. You could roll your own shell script to check the version of python used, or force people to download the package and test it, or worse, distribute python with your package (something OS X people have to do if they need a version other than what Apple ships) -- or you can simply make your package depend on Python, and let the system handle everything else.
I mean if they have to choose between rolling their own service or, rolling their own slightly less functional service and trying to write a script for each of the many existing package managers, why should they do the latter?
Well, they could just pick one. Frankly, the only package manager out there that I think is worth considering is dpkg. The only other that's even remotely popular is rpm, and it's horribly broken, both technologically and politically. I liked Gentoo, but Gentoo/Portage packages are basically scripts anyway, and it's trivial for them to wrap other packaging systems -- in fact, they do it all the time.
So, distribute debs via a repository -- which is simple enough that even a small project like audacious can run their own (note that it only provides audacious packages) -- and then start talking about whether you want to legally let other people repackage your stuff (for instance, Gentoo). It may be a bit of legal work, but certainly no development time, to support Gentoo or Debian once you support Ubuntu. (Or Gentoo/Ubuntu once you support Debian.)
I think it is vital that a standard for packages and package management include an official registration channel for licensing as well as a standard location within the package for such a license in order to get developers on board.
Fine, as long as you understand that "within the package" is relative. The important part is that the license is delivered to the user before they use the software, and can always be found wherever the software is installed.
The basic idea is not only the ability to extract a portable package from an installed application, but to do so in a very user friendly way. If I drag my application icon into my IM window or e-mail or to a CD, it should "just work." You could do this with great complexity by having the OS recognize those export methods...
It already has to, to an extent. The example you give with IM is illustrative; most IM clients don't recognize sending more than a single file at once, and a.app is certainly not a single file.
Also, Linux does not have you EVER click directly on where the app is. You click on things like menu entries. I do, however, have an idea for how such a UI could look and work, and how you'd do the backend. I think it's actually somewhat trivial compared to writing a new package manager, which I intend to do anyway.
We're not just talking about music, but also images and movies and the like. Simply having a standardized location within the package greatly simplifies finding these items, means development tools are more likely to make use of that location, and means third party tools designed to extract these and convert them to more common formats know here to look.
Would you be happy if we had standard locations scattered around the filesystem?
In that case, they should call it an open beta and not charge us for it. Or call it a closed beta and charge us, whatever.
As TFA says, we are customers, not investors, and we should expect to be treated as such. So if everyone took your advice, Vanguard would be dead. Which means that if I do check it out in six months, and buy it (which I might), I will essentially be buying a game that's funded by idiots.
I don't have a problem with it being funded by idiots, but I would much rather games be released whole and complete, so expansions can just be new, cool stuff.
If a company didn't release patches, people would begin to think they're leaving their product unsecure or something.
Or just out of date. And they'd be right; for one thing, Vista breaks games.
No, the model you want to look for is id software. Game works flawlessly out of the box, only problem is they can take awhile on their Linux/Mac binaries. Once released, they patch it, and patch it, and patch it, until they don't want to patch it anymore and just release the source, so we can keep it rolling.
Patches are a good thing. Relying on patches to fix your fuckups is a bad thing. But there's a big difference between something that's essentially alpha or beta that they expect to patch to release quality, and something that's release candidate quality (think Linux RCs, not Vista RCs), or actual release quality, works pretty much all the time, pretty much anywhere, but it'd still be pretty cool of them to, say, release a patch to support my old Matrox card, or better support my new 64-bit processor.
Only problem is, the Oasis page itself doesn't validate. However, it seems Wikipedia does...
But if the Oasis pages did validate, the basic argument goes like this: "How can they claim to care about standards if they can't even bother to support that most universal standard of standards, HTML?" And indeed, I could still make that argument -- just look at the sad, sad state of affairs that is Internet Explorer's CSS [mis]handling.
I want to download a closed source application that must be registered to use. The developer won't put it in an official repository
That's not the fault of the package manager. The developer could choose to distribute it in a repository and add some sort of license or registration on the "config" step, and have the program refuse to run until it's completed. They could even choose to roll their own repository -- it's actually getting significantly easier, I think, for users to add repositories and install software from them.
However, I suppose you could add this to package managers. They already have support for a generic concept of a license, and I believe Ubuntu will ask you the first time it finds a strange license, and then not ask you again if you say yes.
I have an application that is no longer distributed by the manufacturer anywhere and I want to transfer it to a friend. Further, I need to send it via IM since that is the medium we're communicating in.
So IM isn't the obstacle here, really, it's pulling a package out of your running system. The only package manager I know of that will do this is Gentoo's Portage, but it could serve as a model for others.
I really want to grab the music from a closed source game I bought, but how do I get it out of the game binary?
Games don't store them in the game binary. Just because it's in a.app does not magically mean people will store resources separately, instead of in the binary -- and just because it's a package and a normal binary doesn't mean people will be stupid enough not to put music into some folder, like everyone else.
I know id games store stuff effectively in zipfiles, and I know most of the open source games I have store the music files in the game folder. There's one closed source game that stores the game music in a bunch of gigantic mp3 files, named '.dat'.
I want to transfer all my old software over, rather than trying to find all my licensing keys and insert them into a freshly downloaded copy.... With OS X, both binaries are included in the package and it runs seamlessly, while on Linux it does not.
Assuming they were universal binaries in the first place. Otherwise, it's using emulation, which Linux can do also -- though not even close to seamlessly.
However, assuming most of this was commercial software, the right thing for a package manager to do would be to give you an easy way to grab all your license keys and a list of software, and let it re-download everything.
And I know not all software will let you do that; some must be installed using the installer, or from a DVD. But if they would use our packaging scheme, then the only downside here is bandwidth. It could even be made to be intelligent about grabbing what it needs off the old laptop.
With OS X style packages I can just drag it onto the thumb drive and it works without any hassle, because the packages are designed to be portable, with Linux I probably have to get a special version of the software that is designed with portable drives in mind (like portable firefox).
True enough. This is probably your trickiest use case, and the best way to do this on our existing package management systems would be to give them a button to create a portable copy -- but to treat it as another Linux installation target. Worst case, you could chroot onto the thumb drive.
I'm implementing a security system that uses MACLs to restrict applications from access to anything they don't need, where can the develop store an ACL to describe what the binary should be doing within the application? Where is a standard location the application can write its own files to that does not interfere with any other application and is nicely contained?
Generally, if it's a global, persistant database, it would go in
A simple icon on the desktop for turning it off and on
Which defeats the purpose of having it completely separated from the OS. If I turn it off because I don't want them tracking me, how does it automatically get turned back on when it's stolen? If I can do it remotely, how do I trust the company not to?
Yours could, but it's tricky -- and I think mine could, also. Network devices used to be implemented as files, and now they're not. I suppose there could be a compatibility layer, it just strikes me as somewhat fragile.
But go ahead and prove me wrong. Implement this in a nice, clean way.
Most programs already do this for me, anyway -- like I said about Postfix. Most daemons do have good reason to be started as root, also -- it lets them drop privileges. For instance, OpenVPN needs its key files in order to establish a connection, but once the connection is open, it can be dropped to nobody.
I'm saying the ports should be treated like any other device/file in Unix, by allowing the administrator to assign group/user privileges.
That would be nice -- but that requires a large chunk of kernel code -- and, like I said, this has apparently been discarded before.
Doesn't this fit in with the Unix model, instead of some arbitrary and unflexible rule that "the first 1,024 ports are root only"
No, now you're installing arbitrary policy into the kernel.
or some ad hoc, suboptimal, or complex workaround?
Ah. See, my first solution, I thought was actually somewhat elegant. That's the thing about sudo and setuid, they can be used to implement almost anything, which means the kernel doesn't have to know anything beyond "only root can access these".
The Unix model is more about creating a simple set of primitives from which you can build anything you need. So, setuid fits more into that model -- just as, with sudo, the only thing the kernel has to know is setuid, and then sudo can implement its own policy about what commands the user is actually allowed to run.
But you may be right, it may be time to replace parts of the current model. But if it is, I'm not sure you've got the right idea here. I do have an elaborate plan to replace Unix, but before I do, I'm trying to understand it as thoroughly as I can.
Those commands are for updating the system (not installing a brand-new package), and in the very next paragraph, I described how Ubuntu provides a very nice GUI for doing the exact same thing.
Even supposing you did need to use a commandline, it is not difficult to find one, nor is it particularly difficult to copy and paste my commands into that shell.
Also: "Wait for someone else to get around to adding it to the repository" is kind of like "Wait for someone else to actually develop the software". Completely irrelevant, when most of the software is already going to be in some sort of repository, I just Google for "<app> Ubuntu repository". Some apps actually distribute their own repositories -- audacious has its own Ubuntu repository. Synaptic does provide a GUI for changing repositories (which then edits your sources.list for you), and also provides a nice GUI for searching for an app in a repository.
You could whine "But when I tried Linux five years ago, I couldn't find an app I really wanted in a repository!" Which would be kind of like whining that the app you wanted on Windows was only available for download as a zipfile. If it would have an installer.exe on Windows, or a nice.app on OS X, it most certainly does have some sort of package on Ubuntu.
You also seem to have carefully ignored how clicking on the download link is the beginning of a fairly long process, compared to checking a box and hitting "Apply" in Synaptic.
Your knee is jerking. Please don't reflexively dismiss an entire post because it mentions (gasp!) a commandline.
Erm... no, I know why OOP is a good thing. I don't know why Java OOP is any better than C++ "tacked on" OOP.
Explain to me why it is a good thing that the class "Object" exists? It seems to me that the only time you actually need to use it is when forceably typecasting stuff in a very un-OO-like manner.
Java's main limitations are ones that you will have with any bytecode environment. It isn't easy to access platform specific features
Except C# and.NET make this ridiculously easy, and are still somewhat cross-platform, thanks to Mono. What's Java's excuse?
There actually is someone I was talking to about a language he was creating, which sounds perfect. But therein lies the problem -- creating. Still nothing actually finished yet.
On Windows, I go to mozilla.com, click the download link, click "open", then click "yes" at a security prompt, and if I'm lucky (and no one's intercepted the download), I actually get Firefox, and not Firefox+spyware.
On OSX, I go to mozilla.com, click the download link, save it somewhere, doubleclick the file to "mount" it, then drag it to Applications, then "eject" the image, then throw it away, then empty my trash.
Those are the FASTEST ways to install Firefox on either of those OSes.
On Gentoo, I type "emerge firefox". On Ubuntu, I type "apt-get install firefox".
That it installs a million other packages is irrelevant -- those "million other packages" are also going to be downloaded on Windows or OSX, the difference is that they HAVE to be downloaded, even if more than one app uses them. This is called "shared libraries", and every single time I talk to people about this, they either agree that Linux package management is a good idea, or decide they'd rather waste disk space and RAM by doing it the Mac way.
And yes, I do wish there were decent package management systems for Windows or OSX. In fact, there are -- there's one called "Windows Update", and another called "Software Update". In fact, for a taste of how package management could work on Windows, you could go to the Windows Update website, find the.NET runtime, check the box for it, and click "install", and watch while it downloads everything needed to install it and bring it up to date. Unfortunately, these are both fairly primitive (when compared to Unix package management systems) and closed to everyone except Microsoft and Apple.
Which means that on Windows, to update my system, I have to check nvidia.com for new video drivers, mozilla.com in case there's an update that Firefox or Thunderbird won't automagically download (it's happened before), update.microsoft.com for Windows updates, then Office Update for Office updates (since I have an older version of office which won't be updated through Microsoft update), launch Steam and poke it in several different ways to make sure it actually checks for updates, then Clamwin for a new version of their anti-virus software -- they'll download virus definitions automatically, but not new versions of the software -- then Creative Labs for new sound drivers... And let's not forget, many of these will require a reboot, and certainly the Windows Update stuff will refuse to install any more updates until you reboot with the last updates, meaning if you let it go for awhile, you could easily have to reboot 4-5 times.
And I only use Windows to occasionally test stuff in Office (in case OpenOffice fails), or play Steam games.
On OSX, at least I don't have to reboot. However, I did have to check Firefox, Thunderbird, Sunbird (which hasn't ever automatically updated itself), Software Update, Chicken of the VNC, Python, Java, Adium, Growl, Neverball, TunnelBlick and OpenVPN, rdesktop, Microsoft's own remote desktop software, mplayer, mencoder, VLC, CyberDuck, Acrobat Reader, and iCab. Individually, by browsing to their websites, or opening the program and clicking "check for updates". Some of them will update automatically, most of them won't, and it's hard to tell by looking at them which are automatic and which aren't -- and the ones which aren't won't update unless I open them, meaning if I leave a program for a few months, I might open it and find 2-3 updates waiting for me.
I used OS X every day for work, until my Powerbook died.
Both of the above scenarios will often involve me actually having to download a patch, or a new version, manually from the website -- in yet another easy-to-intercept vanilla HTTP connection.
On Linux, on Gentoo, I type these two commands:
emerge sync emerge -uaDN world
On Ubuntu, it's even easier:
apt-get update apt-get dist-upgrade
That will update absolutely EVERYTHING on my system. And on the Ubuntu side, no matter what repositories I'm set up for, the system will
I like Java because it has a base object unlike c++ which is c with objects tacked on.
Great! Now explain to me why this is a good thing.
It has handled 300,000 support calls and I don't know how many RMAs over the years with no problems.
Alright, I'll give you this one.
I'm still looking for a language that is powerful, flexible, bytecode-portable, and at least close to as fast as C. Java may have the last two -- maybe -- but it's sadly lacking in the first two.
Ok, let's assume your admin is root, or is able to run commands as root (through sudo). Let's also assume we have setuid bits, as I've never run into a Unix that doesn't.
Right now, we have the very inflexible approach, where the first 1024 ports are considered "privileged", and only root may bind to them. We also have a bunch of users with daemons designed to bind to some of those ports.
There are actually several really easy ways for root to handle this. The first, and most obvious, is to simply run xinetd, which is an internet superserver. It allows you to define services -- each service is a configuration of a port for xinetd to listen on and a program to execute when a connection is found. That program's standard input and output is connected to the connection.
So, only root can configure xinetd, but root can certainly configure it to run daemons as users -- supposing I wanted to be the one in charge of SMTP, I could simply ask root to forward port 25 connections to/home/sanity/bin/smtp, and run it as me.
Actually, I don't remember whether xinetd allows you to change the user under which a command is run, but that doesn't matter. The admin could easily customize that command to point to my user -- just put "su sanity -c/home/sanity/bin/smtp" as the command to run.
This may not provide as much control as you want, of course -- users can't control whether a port is open or closed. It's certainly less efficient; a new process must be spawned for every connection -- although that is more efficient if you have a lot of services that are connected to almost never, so you won't actually need any daemons running most of the time except xinetd.
But if you wanted to make it better, it seems like it would be much easier to write something like xinetd, or even just a small program runnable under sudo. It is possible (though tricky) to pass open sockets through to exec()'d programs, and even if it weren't, one could always write a server which bound to a socket, dropped privileges, and then called a user-defined library.
The downside to this is, of course, you have to write daemons to expect one of the above approaches. If you want to work with existing programs -- for instance, if you want to be able to start Apache unprivileged -- that is when you would start to implement something more complex. At this point, SELinux probably provides what you want, but it also requires kernel patches and introduces a LOT more complexity for the admin to manage than simple xinetd rules. However, properly configured, SELinux should allow you to run most existing stuff unmodified -- if I understand it right, you could probably configure apache to be allowed to open port 80 (even when not run as root), or even configure it to run as root, but not be allowed to do anything other than open a port and drop privileges.
I still like the root-only approach, though, as it's very simple and very clean, especially in terms of kernel code. The kernel only has to check whether it's a privileged port, and whether the user is root -- all the complexity is pushed out to userspace.
Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding. It's hard to make a good case against C, though -- most things that are possible in other languages are possible in C, yet there are plenty of things that are possible in C which are not really possible in other languages. For example, I wouldn't consider writing a kernel in Java -- yet.
I don't use C, but I also don't think other projects are making some hugely horrific mistake in choosing it over another language. It's possible to write bad code in any language, so you should base your choice more on what you can do with it than how many ways you can screw up. This is also an argument for Perl, by the way -- just because it's possible to write Perl code that looks like line noise shouldn't stop you from using it. And just because Java is going to force you to write cleaner-looking, more verbose, documented (for your own sake) code doesn't mean you should automatically choose Java instead of Perl.
Personally, I prefer shell scripts when they make sense, and Perl when it's too much to sanely do in bash. But that's convenience.
On Windows, doesn't plugging in an iPod generally involve making it into a removable device? And don't removable devices on Windows generally get AutoRun? Done right, you could even install enough of a rootkit to hide the fact that it is set to autorun.
It wouldn't be a perfect solution, of course -- but neither is the iTunes approach. Either one becomes irrelevant when I just use Linux to access it as a mass storage device and possibly some open source stuff to access the files.
And of course, stolen iPods are only a few hundred dollars or so, right? And you have to have all the music on your desktop in iTunes, right? So it's not even close to losing a laptop, for which you may or may not have a backup, but either way is probably going to cost you a couple thousand dollars.
Ideally, this would be a separate piece of hardware, included in every laptop (or maybe other things you don't want to lose?), ideally in such a way that removing it would be prohibitively expensive and easily possible to destroy the laptop if removed. Wire it directly to the GPS and maybe EDGE, and have it silently wake up and broadcast at regular intervals, whether the device is enabled or not, whether the battery is in or not.
The real trick is preventing this from being abused by people who would like to track your every move. I'll leave that as an exercise to the reader, I don't want to think too hard about whether it's even possible to make it reasonably private. However, I believe some cars already do something like this, and I imagine it's reasonable to hide it in a laptop. At the very least, it would discourage any idiot from just grabbing it and walking off with it -- any idiot can operate a computer, most people off the street won't know how to use a soldering iron, and that's only the first step in actual hardware hacking.
And unlike software, it's not cheap or easy to just wholesale replace the hardware in a laptop, in case some of it is bugged.
Slashdot Mirror
As far as I know, anything on the system can create something that looks like a valid UAC box, dim the screen, etc. Certainly, I'd imagine this to be the case on OS X or Linux (with sudo or whatever). So, with just a simple yes/no dialog (or allow/deny), you can click "yes" on anything, but it's only a problem if you click "yes" to an actual UAC box without reading it. They can spoof a passwordless UAC box all they want, but if you don't click "yes", it won't do anything.
However, if they popup something that looks identical to a UAC box, but captures your password, well, they now have your password. Certainly this is a problem on Linux/OSX, as su (and sudo) don't really attempt to go farther than making sure they're reading directly from a terminal -- usually a pseudoterminal, meaning it's just a bit more annoying to find a way to pipe a password into sudo.
So, without doing the research, my question is:
It does seem appropriate -- they both are directly responsible for all Hell breaking loose.
Reading these articles and the comments here, it would seem that wine has a much better chance of being efficient than cygwin ever will, simply because UNIX APIs tend to be sensibly lower level. So, cygwin is a bit like trying to implement, say, C or C++ on top of C#. You could do it, but it would be much more efficient to build C# on top of C or C++, and, in fact, we do (Mono is written in C++, if I remember right).
As I understand it, Linux processes are lightweight enough that modern pthreads on Linux builds on top of fork/exec. Or something like that -- one is a wrapper for the other, I think.
In any case, reading through your suggestions, the only real difference is that if you're writing in C (and thus vulnerable to buffer overflows), segfaulting a process won't bring down the entire app. One other difference is that fork/exec would tend to be easy to make distributed, as most of your communication would be in pipes. However, both of these ultimately come down to how the app is written, not what language or API you're using.
So, the only real difference will be performance implications. On Windows, it's MUCH cheaper to spawn a thread than a process, and there is no fork, so on Windows, monolithic monstrosities are the only viable way to go.
Problem: What if one significant reason a Linux machine is better than a Windows machine is the lack of malware? Thus, a fresh (non-OEM) Windows install will get loaded with malware infinitely faster than a fresh Linux install, as the Linux install will never get hit with malware.
Now, if you install malware from the beginning (with crapplets), Linux completely loses that advantage. Granted, it may still be an improvement, but it becomes one hell of a baby step. It's hardly a free/open platform if it comes with BonziBuddy Unix Edition. (Yes, I made that up -- I'll insult BonziBuddy till they sue me, and then I'll switch over to insulting Gator or something.)
I will buy a Dell for my next laptop, if it comes preloaded with a decent Linux distro and without a bunch of crap. (I will not pay for the crap.)
I'll even buy it if it isn't a distro I like.
However' if you really want to blow us away, Dell, give us a few of the configurable install options available via the website -- preferably without Flash or excessive JavaScript required. Maybe a web-based debian-installer? Because I'd like to be able to choose filesystem, partitioning scheme, and base distro (maybe from a limited selection -- hell, just Ubuntu and Fedora would probably satisfy most people who would care about pre-installed). I want to be able to choose these not because I am such a nerd, but because they aren't easy to change after an install -- which is probably why Dell lets you choose FAT32 or NTFS when ordering an XP computer.
Hey, Anonymous Troll, you obviously haven't found the right users.
I do appreciate Dell doing this. Really, I do.
But I fear the coming of the Linux Crapplets. I fear what happens when AOL starts placing icons on my Gnome desktop.
And I pray that Dell does the right thing and drops the crapplets -- insist that they stop paying per machine sold and start just paying for Windows licenses sold, and use the money saved there to avoid preloading random crap other than the OS.
See, Blizzard does get a bit of credit for actually working with Cedega to fix World of Warcraft problems. None of the other companies you mentioned have done anything to improve their karma.
And this is what bothers me about the corporation, specifically the conglomerate. I like Bungie, and I like the Halo series, but I hate Microsoft.
So, Halo and Halo 2 was worth buying an Xbox for, and Halo 3 will be worth buying a 360 for, but neither is worth selling my soul for. So I borrow them from friends.
There's a more fundamental problem, maybe the same cause: Lack of competition and standards, and huge organizations, makes it very hard to separate the good from the bad. I can't buy a Halo game without supporting Microsoft indirectly by paying Bungie, and directly by buying an Xbox (because they mostly aren't available on a non-Microsoft platform).
If I already have to implement my own login mechanism and host my own "website" of pages, why shouldn't I just roll my own HTTP server entirely?
Here's hoping they find a way to save time by using the existing package managers. I know I would. Dependencies alone is a pretty big deal -- for instance, suppose you ship a product written in python. You could roll your own shell script to check the version of python used, or force people to download the package and test it, or worse, distribute python with your package (something OS X people have to do if they need a version other than what Apple ships) -- or you can simply make your package depend on Python, and let the system handle everything else.
Well, they could just pick one. Frankly, the only package manager out there that I think is worth considering is dpkg. The only other that's even remotely popular is rpm, and it's horribly broken, both technologically and politically. I liked Gentoo, but Gentoo/Portage packages are basically scripts anyway, and it's trivial for them to wrap other packaging systems -- in fact, they do it all the time.
So, distribute debs via a repository -- which is simple enough that even a small project like audacious can run their own (note that it only provides audacious packages) -- and then start talking about whether you want to legally let other people repackage your stuff (for instance, Gentoo). It may be a bit of legal work, but certainly no development time, to support Gentoo or Debian once you support Ubuntu. (Or Gentoo/Ubuntu once you support Debian.)
Fine, as long as you understand that "within the package" is relative. The important part is that the license is delivered to the user before they use the software, and can always be found wherever the software is installed.
It already has to, to an extent. The example you give with IM is illustrative; most IM clients don't recognize sending more than a single file at once, and a .app is certainly not a single file.
Also, Linux does not have you EVER click directly on where the app is. You click on things like menu entries. I do, however, have an idea for how such a UI could look and work, and how you'd do the backend. I think it's actually somewhat trivial compared to writing a new package manager, which I intend to do anyway.
Would you be happy if we had standard locations scattered around the filesystem?
Oh,
In that case, they should call it an open beta and not charge us for it. Or call it a closed beta and charge us, whatever.
As TFA says, we are customers, not investors, and we should expect to be treated as such. So if everyone took your advice, Vanguard would be dead. Which means that if I do check it out in six months, and buy it (which I might), I will essentially be buying a game that's funded by idiots.
I don't have a problem with it being funded by idiots, but I would much rather games be released whole and complete, so expansions can just be new, cool stuff.
Or just out of date. And they'd be right; for one thing, Vista breaks games.
No, the model you want to look for is id software. Game works flawlessly out of the box, only problem is they can take awhile on their Linux/Mac binaries. Once released, they patch it, and patch it, and patch it, until they don't want to patch it anymore and just release the source, so we can keep it rolling.
Patches are a good thing. Relying on patches to fix your fuckups is a bad thing. But there's a big difference between something that's essentially alpha or beta that they expect to patch to release quality, and something that's release candidate quality (think Linux RCs, not Vista RCs), or actual release quality, works pretty much all the time, pretty much anywhere, but it'd still be pretty cool of them to, say, release a patch to support my old Matrox card, or better support my new 64-bit processor.
Only problem is, the Oasis page itself doesn't validate. However, it seems Wikipedia does...
But if the Oasis pages did validate, the basic argument goes like this: "How can they claim to care about standards if they can't even bother to support that most universal standard of standards, HTML?" And indeed, I could still make that argument -- just look at the sad, sad state of affairs that is Internet Explorer's CSS [mis]handling.
That's not the fault of the package manager. The developer could choose to distribute it in a repository and add some sort of license or registration on the "config" step, and have the program refuse to run until it's completed. They could even choose to roll their own repository -- it's actually getting significantly easier, I think, for users to add repositories and install software from them.
However, I suppose you could add this to package managers. They already have support for a generic concept of a license, and I believe Ubuntu will ask you the first time it finds a strange license, and then not ask you again if you say yes.
So IM isn't the obstacle here, really, it's pulling a package out of your running system. The only package manager I know of that will do this is Gentoo's Portage, but it could serve as a model for others.
Games don't store them in the game binary. Just because it's in a .app does not magically mean people will store resources separately, instead of in the binary -- and just because it's a package and a normal binary doesn't mean people will be stupid enough not to put music into some folder, like everyone else.
I know id games store stuff effectively in zipfiles, and I know most of the open source games I have store the music files in the game folder. There's one closed source game that stores the game music in a bunch of gigantic mp3 files, named '.dat'.
Assuming they were universal binaries in the first place. Otherwise, it's using emulation, which Linux can do also -- though not even close to seamlessly.
However, assuming most of this was commercial software, the right thing for a package manager to do would be to give you an easy way to grab all your license keys and a list of software, and let it re-download everything.
And I know not all software will let you do that; some must be installed using the installer, or from a DVD. But if they would use our packaging scheme, then the only downside here is bandwidth. It could even be made to be intelligent about grabbing what it needs off the old laptop.
True enough. This is probably your trickiest use case, and the best way to do this on our existing package management systems would be to give them a button to create a portable copy -- but to treat it as another Linux installation target. Worst case, you could chroot onto the thumb drive.
Generally, if it's a global, persistant database, it would go in
There are plenty of portability libraries. In C, as in Perl, most of the porting has already been done for you.
Of those, I've looked at Erlang, and as far as I can tell, it's too slow and inflexible. And yes, I know it's used in mobile phones, etc.
I should've said, I don't use it for my own stuff. I do occasionally hack around in C, and I see people doing good stuff there.
By this, do you mean, chances for any errors, or a number of them? I'd say, look at the Linux kernel lately.
I intend to stay as far away from C as I can, most of the time. I just don't think it's the only "right way".
Which defeats the purpose of having it completely separated from the OS. If I turn it off because I don't want them tracking me, how does it automatically get turned back on when it's stolen? If I can do it remotely, how do I trust the company not to?
Yours could, but it's tricky -- and I think mine could, also. Network devices used to be implemented as files, and now they're not. I suppose there could be a compatibility layer, it just strikes me as somewhat fragile.
But go ahead and prove me wrong. Implement this in a nice, clean way.
Most programs already do this for me, anyway -- like I said about Postfix. Most daemons do have good reason to be started as root, also -- it lets them drop privileges. For instance, OpenVPN needs its key files in order to establish a connection, but once the connection is open, it can be dropped to nobody.
That would be nice -- but that requires a large chunk of kernel code -- and, like I said, this has apparently been discarded before.
No, now you're installing arbitrary policy into the kernel.
Ah. See, my first solution, I thought was actually somewhat elegant. That's the thing about sudo and setuid, they can be used to implement almost anything, which means the kernel doesn't have to know anything beyond "only root can access these".
The Unix model is more about creating a simple set of primitives from which you can build anything you need. So, setuid fits more into that model -- just as, with sudo, the only thing the kernel has to know is setuid, and then sudo can implement its own policy about what commands the user is actually allowed to run.
But you may be right, it may be time to replace parts of the current model. But if it is, I'm not sure you've got the right idea here. I do have an elaborate plan to replace Unix, but before I do, I'm trying to understand it as thoroughly as I can.
...because you obviously didn't read it.
.exe on Windows, or a nice .app on OS X, it most certainly does have some sort of package on Ubuntu.
Those commands are for updating the system (not installing a brand-new package), and in the very next paragraph, I described how Ubuntu provides a very nice GUI for doing the exact same thing.
Even supposing you did need to use a commandline, it is not difficult to find one, nor is it particularly difficult to copy and paste my commands into that shell.
Also: "Wait for someone else to get around to adding it to the repository" is kind of like "Wait for someone else to actually develop the software". Completely irrelevant, when most of the software is already going to be in some sort of repository, I just Google for "<app> Ubuntu repository". Some apps actually distribute their own repositories -- audacious has its own Ubuntu repository. Synaptic does provide a GUI for changing repositories (which then edits your sources.list for you), and also provides a nice GUI for searching for an app in a repository.
You could whine "But when I tried Linux five years ago, I couldn't find an app I really wanted in a repository!" Which would be kind of like whining that the app you wanted on Windows was only available for download as a zipfile. If it would have an installer
You also seem to have carefully ignored how clicking on the download link is the beginning of a fairly long process, compared to checking a box and hitting "Apply" in Synaptic.
Your knee is jerking. Please don't reflexively dismiss an entire post because it mentions (gasp!) a commandline.
Erm... no, I know why OOP is a good thing. I don't know why Java OOP is any better than C++ "tacked on" OOP.
Explain to me why it is a good thing that the class "Object" exists? It seems to me that the only time you actually need to use it is when forceably typecasting stuff in a very un-OO-like manner.
Except C# and .NET make this ridiculously easy, and are still somewhat cross-platform, thanks to Mono. What's Java's excuse?
There actually is someone I was talking to about a language he was creating, which sounds perfect. But therein lies the problem -- creating. Still nothing actually finished yet.
On Windows, I go to mozilla.com, click the download link, click "open", then click "yes" at a security prompt, and if I'm lucky (and no one's intercepted the download), I actually get Firefox, and not Firefox+spyware.
.NET runtime, check the box for it, and click "install", and watch while it downloads everything needed to install it and bring it up to date. Unfortunately, these are both fairly primitive (when compared to Unix package management systems) and closed to everyone except Microsoft and Apple.
On OSX, I go to mozilla.com, click the download link, save it somewhere, doubleclick the file to "mount" it, then drag it to Applications, then "eject" the image, then throw it away, then empty my trash.
Those are the FASTEST ways to install Firefox on either of those OSes.
On Gentoo, I type "emerge firefox". On Ubuntu, I type "apt-get install firefox".
That it installs a million other packages is irrelevant -- those "million other packages" are also going to be downloaded on Windows or OSX, the difference is that they HAVE to be downloaded, even if more than one app uses them. This is called "shared libraries", and every single time I talk to people about this, they either agree that Linux package management is a good idea, or decide they'd rather waste disk space and RAM by doing it the Mac way.
And yes, I do wish there were decent package management systems for Windows or OSX. In fact, there are -- there's one called "Windows Update", and another called "Software Update". In fact, for a taste of how package management could work on Windows, you could go to the Windows Update website, find the
Which means that on Windows, to update my system, I have to check nvidia.com for new video drivers, mozilla.com in case there's an update that Firefox or Thunderbird won't automagically download (it's happened before), update.microsoft.com for Windows updates, then Office Update for Office updates (since I have an older version of office which won't be updated through Microsoft update), launch Steam and poke it in several different ways to make sure it actually checks for updates, then Clamwin for a new version of their anti-virus software -- they'll download virus definitions automatically, but not new versions of the software -- then Creative Labs for new sound drivers... And let's not forget, many of these will require a reboot, and certainly the Windows Update stuff will refuse to install any more updates until you reboot with the last updates, meaning if you let it go for awhile, you could easily have to reboot 4-5 times.
And I only use Windows to occasionally test stuff in Office (in case OpenOffice fails), or play Steam games.
On OSX, at least I don't have to reboot. However, I did have to check Firefox, Thunderbird, Sunbird (which hasn't ever automatically updated itself), Software Update, Chicken of the VNC, Python, Java, Adium, Growl, Neverball, TunnelBlick and OpenVPN, rdesktop, Microsoft's own remote desktop software, mplayer, mencoder, VLC, CyberDuck, Acrobat Reader, and iCab. Individually, by browsing to their websites, or opening the program and clicking "check for updates". Some of them will update automatically, most of them won't, and it's hard to tell by looking at them which are automatic and which aren't -- and the ones which aren't won't update unless I open them, meaning if I leave a program for a few months, I might open it and find 2-3 updates waiting for me.
I used OS X every day for work, until my Powerbook died.
Both of the above scenarios will often involve me actually having to download a patch, or a new version, manually from the website -- in yet another easy-to-intercept vanilla HTTP connection.
On Linux, on Gentoo, I type these two commands:
emerge sync
emerge -uaDN world
On Ubuntu, it's even easier:
apt-get update
apt-get dist-upgrade
That will update absolutely EVERYTHING on my system. And on the Ubuntu side, no matter what repositories I'm set up for, the system will
Great! Now explain to me why this is a good thing.
Alright, I'll give you this one.
I'm still looking for a language that is powerful, flexible, bytecode-portable, and at least close to as fast as C. Java may have the last two -- maybe -- but it's sadly lacking in the first two.
...are condemned to reinvent it, poorly.
/home/sanity/bin/smtp, and run it as me.
/home/sanity/bin/smtp" as the command to run.
Ok, let's assume your admin is root, or is able to run commands as root (through sudo). Let's also assume we have setuid bits, as I've never run into a Unix that doesn't.
Right now, we have the very inflexible approach, where the first 1024 ports are considered "privileged", and only root may bind to them. We also have a bunch of users with daemons designed to bind to some of those ports.
There are actually several really easy ways for root to handle this. The first, and most obvious, is to simply run xinetd, which is an internet superserver. It allows you to define services -- each service is a configuration of a port for xinetd to listen on and a program to execute when a connection is found. That program's standard input and output is connected to the connection.
So, only root can configure xinetd, but root can certainly configure it to run daemons as users -- supposing I wanted to be the one in charge of SMTP, I could simply ask root to forward port 25 connections to
Actually, I don't remember whether xinetd allows you to change the user under which a command is run, but that doesn't matter. The admin could easily customize that command to point to my user -- just put "su sanity -c
This may not provide as much control as you want, of course -- users can't control whether a port is open or closed. It's certainly less efficient; a new process must be spawned for every connection -- although that is more efficient if you have a lot of services that are connected to almost never, so you won't actually need any daemons running most of the time except xinetd.
But if you wanted to make it better, it seems like it would be much easier to write something like xinetd, or even just a small program runnable under sudo. It is possible (though tricky) to pass open sockets through to exec()'d programs, and even if it weren't, one could always write a server which bound to a socket, dropped privileges, and then called a user-defined library.
The downside to this is, of course, you have to write daemons to expect one of the above approaches. If you want to work with existing programs -- for instance, if you want to be able to start Apache unprivileged -- that is when you would start to implement something more complex. At this point, SELinux probably provides what you want, but it also requires kernel patches and introduces a LOT more complexity for the admin to manage than simple xinetd rules. However, properly configured, SELinux should allow you to run most existing stuff unmodified -- if I understand it right, you could probably configure apache to be allowed to open port 80 (even when not run as root), or even configure it to run as root, but not be allowed to do anything other than open a port and drop privileges.
I still like the root-only approach, though, as it's very simple and very clean, especially in terms of kernel code. The kernel only has to check whether it's a privileged port, and whether the user is root -- all the complexity is pushed out to userspace.
Assembly is not portable. C is.
Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding. It's hard to make a good case against C, though -- most things that are possible in other languages are possible in C, yet there are plenty of things that are possible in C which are not really possible in other languages. For example, I wouldn't consider writing a kernel in Java -- yet.
I don't use C, but I also don't think other projects are making some hugely horrific mistake in choosing it over another language. It's possible to write bad code in any language, so you should base your choice more on what you can do with it than how many ways you can screw up. This is also an argument for Perl, by the way -- just because it's possible to write Perl code that looks like line noise shouldn't stop you from using it. And just because Java is going to force you to write cleaner-looking, more verbose, documented (for your own sake) code doesn't mean you should automatically choose Java instead of Perl.
Personally, I prefer shell scripts when they make sense, and Perl when it's too much to sanely do in bash. But that's convenience.
On Windows, doesn't plugging in an iPod generally involve making it into a removable device? And don't removable devices on Windows generally get AutoRun? Done right, you could even install enough of a rootkit to hide the fact that it is set to autorun.
It wouldn't be a perfect solution, of course -- but neither is the iTunes approach. Either one becomes irrelevant when I just use Linux to access it as a mass storage device and possibly some open source stuff to access the files.
And of course, stolen iPods are only a few hundred dollars or so, right? And you have to have all the music on your desktop in iTunes, right? So it's not even close to losing a laptop, for which you may or may not have a backup, but either way is probably going to cost you a couple thousand dollars.
Ideally, this would be a separate piece of hardware, included in every laptop (or maybe other things you don't want to lose?), ideally in such a way that removing it would be prohibitively expensive and easily possible to destroy the laptop if removed. Wire it directly to the GPS and maybe EDGE, and have it silently wake up and broadcast at regular intervals, whether the device is enabled or not, whether the battery is in or not.
The real trick is preventing this from being abused by people who would like to track your every move. I'll leave that as an exercise to the reader, I don't want to think too hard about whether it's even possible to make it reasonably private. However, I believe some cars already do something like this, and I imagine it's reasonable to hide it in a laptop. At the very least, it would discourage any idiot from just grabbing it and walking off with it -- any idiot can operate a computer, most people off the street won't know how to use a soldering iron, and that's only the first step in actual hardware hacking.
And unlike software, it's not cheap or easy to just wholesale replace the hardware in a laptop, in case some of it is bugged.