I'll add my vote for a text installer here. I helped a friend install Debian on an old (and very weird) computer, and had some trouble getting X working; it turned out that his graphics card (3DLabs, I think?), unlike 99% of other PC graphics cards, didn't support VESA, the lowest-common-denominator standard for graphics. A card-specific video driver worked, text mode worked, but there was nothing in between.
I suspect that if the installer had tried to go into a VESA framebuffer mode (like just about every other x86 Linux installer does), we'd never have got it installed in the first place.
[If it's not obvious: italic text comes from the parent post, which has already been modded into oblivion.]
I like Debian because it works on my Powerbook (big-endian non-x86 architecture with slightly odd hardware) just as well as it does on my (ordinary, mainstream) PC, and because it also managed to work on my friend's mutant box-of-bits (Cyrix 500MHz cheap-knock-off CPU, ancient AT keyboard port, USB mouse due to no PS/2 ports, serial and parallel ports on an expansion card, graphics card that didn't do VESA... the thing was extremely dodgy).
I also like
- the fact that the packages are made by control freaks (in the nicest possible sense of the words...) who care about consistency and things working nicely together to a sufficient extent that they have formal policies for large classes of packages, but package things in such a way that you can apply local hacks if you don't like how they did it, and make a great effort to preserve local changes to configuration
- the way the development process is usually as transparent and open as the source code of the packages themselves
- the fact that they've built a complete operating system out of software held to standards of freedom and openness high enough that even the Free Software Foundation's "Free Documentation License" doesn't qualify.
- the fact that no one entity controls Debian, so as long as someone's interested in developing for it, it won't go away
- the social contract that sets out the principles Debian will work by.
Debian sucks because Debian rocks because
* Out dated packages, even in unstable * Packages are tested (and compiled on more architectures than I care to imagine), and even unstable is actually usable
* Buggy and hard to use installer, people are told to use 3rd party installers because the developers cant be assed to fix it * A text-mode installer which doesn't blithely assume that graphics mode works properly, or even that you *want* graphics mode (very handy if your hardware is bizarre, like my friend's old PC which couldn't do some of the standard VESA video modes)
* More security flaws than any other distro [To parent: Really? Please provide links to back that up, I'm interested] * A transparent mechanism for security updates and bulletins which doesn't introduce new and untested code at the same time, and takes all reported security flaws seriously
* Contains too many redundant and legacy apps * Contains a huge choice of apps
* All the people who actually used Debian have fled to other distros such as Slackware, Gentoo and Fedora. Only the eleetist pricks are left now * um... how to answer that one... how about "I actually use Debian, you insensitive clod?";-)
Mac OS X just works. It has applications that I need to get along. I like having some games. I like having stuff like iSync & iTunes. Yes, I know there's Linux apps, but I like how everything works *together* and isn't an ugly kludge.
That's fine, as long as the stuff that works *together* is all you need or want...
I think Linux has a loooong way to go as a desktop OS. The word from LinuxWorld was "It's not quite there yet.." which means that other people feel the same way.
The thing about "Linux On The Desktop" (tm) is that not everyone wants the same desktop. Most people without a programmer mindset would get frustrated by my usual desktop environment (at the moment, my window list consists of Firebird and 4 xterms - one of them is a MP3 player, one is my e-mail, two are sitting at shell prompts). On the other hand, I'd probably get frustrated by their desktop environment, on the basis that I couldn't get at my Unix shell. Linux is ready for *some people's* desktops, and it has been so for years.
Personally I think KDE's getting close to being usable by the "average computer user", if there is such a thing, and is way ahead in some ways. (I can't comment on Gnome, since I haven't used it since well before Gtk2.)
---- (Warning: this comment is an extended brain-dump.) ----
I bought a Powerbook as my primary computer, because I was sick of my Athlon's excessive and loud cooling system (2 case fans, PSU fan, CPU fan, 2 graphics card fans...), but also to give Mac OS X a go.
My choice was between a then-current (but getting old) 15" titanium Powerbook, or either getting a then-current 12" or 17" aluminium Powerbook or waiting for the 15" equivalent. It basically came down to: would I use Linux or Mac OS X? If I was happy in OS X, an AlBook would be better value (802.11g, Bluetooth, Firewire 800, lit keyboard, Geforce 4) but if I wanted to use Linux, the slightly older tech in a TiBook (802.11b, Firewire 400, ATi Radeon) would give me better compatibility. I went for the TiBook, and I'm really glad I did.
Mac OS X is a very nice OS - easy, reliable and pretty-looking - but for "hackability", give me a Free/open-source OS like Linux or a BSD any day. In Mac OS, yes, there's the underlying Darwin layer, but to do anything non-standard with it I'll have to "fight the system".
In Linux (Debian is my weapon of choice) I can just tell The System to get out of my way: on my laptop, I've disabled Debian's networking infrastructure, in favour of writing an ad-hoc networking script that copes better with changing locations, while integrating nicely with IPSec (I use IPSec to control access to my wireless access point, at the request of my college computing service, whose bandwidth it's using). It's inconsistent, it's an ugly kludge which I must tidy up one day, and it's *so* useful.
With its non-standard components (Netinfo being the main one), OS X takes a bit of getting used to for a Unix user; I'm still not entirely comfortable about having a network-accessible daemon holding my user info (I *think* it only listens on localhost, but I could be wrong...), and some of its features are a definite step backwards (any local user has access to crypted (not even MD5ed) passwords, a problem solved on every other Unix system by the introduction of shadow files).
I find some other things about Mac OS limiting: mostly just minor things, but things I'm accustomed to being able to change. The "window manager" (if you can call it that, since it appears to be integrated into the OS) is unconfigurable, which is great from a training point of view, but frustrating if you know what you're doing and want something like sloppy focus, or double-clicking on a title-bar doing something different (I like "window shading" (hiding the window and leaving only the title bar) myself), or whatever. The Dock is a nice shortcut for stuff, but I can't seem to change the icon for a disk image in the Dock in any obvious way (I've imaged my game CDs, so I ca
"Public source" seems to mean the header files to compile against, and the source code for the RTCW:ET-specific bits of the game (i.e. not the engine). This is the same sort of thing as the Half-Life SDK which the original (pre-commercial) Counterstrike was based on.
(For Debian users: if this was in Debian, it'd be a binary package called something like rtcw-enemyterritory-dev:-)
As for the licensing (Polyp2000: thanks for posting the text), many game SDKs have restrictive EULA-like licenses (presumably the publishers insist on them) which mean that the majority of distributed mods for those games are likely technically illegal, as are many activities which an average gamer would probably consider perfectly reasonable.
In this case, among other things, the EULA asserts that you can't back up the SDK to a CD (only to "one (1)" hard disk), and that commercial distribution of a "New Creation" (mod) is not allowed (so magazines which distribute "RTCWstrike", or whatever the next big mod is called, on their cover CDs are potentially in trouble).
This isn't Free Software, it's not Open Source, and indeed the "non-commercial distribution" stipulation probably means it wouldn't even make it into Debian's non-free section.
As with any free hosting service with no minimum quality, mp3.com hosted a lot of talentless bands. However, there was a lot of good stuff there too: Neptune Crush, Misnomer (misnomer.co.uk), Cry, The Cynic Project, Soma, Swiv are some of the (former) mp3.com artists I liked.
CD Wow! faced an injunction after the BPI claimed it was infringing the copyright of its members by sourcing its goods from outside Europe.
(I don't think that should be possible, though... how can CD Wow be infringing copyright if they have nothing to do with the copying process used to make the CDs, but just buy and resell them?)
Case sensitivity is way more ambiguous by allowing
bar and Bar to be different variables whereas in English a bar and a Bar are no different.
That's not ambiguity. Ambiguity is saying one thing which could mean several things; according to your assertion, case-sensitive languages have more than one way (Bar vs bar) to say the same thing.
English isn't case-insensitive, anyway. When you encounter a capital letter, it's telling you something (that it's the beginning of a sentence, or part of a title, or a proper noun,...).
Because lowercase/uppercase could be a harder problem if you use a language which allows Unicode symbols (Perl6?). (Is this possible? I have no idea).
There is no difference, basically. And Java supports uppercase functions for unicode in any case...
There is a huge difference. In the "basic" Roman alphabet (with no accents or anything, as implemented in ASCII) there is a 1-to-1 mapping between upper and lower case; this isn't always true in general.
For instance, in German there is the "s-set" (which looks a lot like a lower-case beta), which is more or less interchangeable with the character pair "ss". It upper-cases to "SS" (i.e. there is no capital s-set). With that in mind, in a case insensitive Unicode-based language, how many of strasse, stra(s-set)e, STRASSE should be equivalent?
Once you've finished hard-coding your case comparison rules, what other equivalences are allowed? Is a-acute ("a" with an acute accent, which Slashcode doesn't seem to want to let me post) the same as "a", bearing in mind that both are conventionally upper-cased to A in French, and is the correct answer "if and only if the programmer is French"?
Being case-sensitive also lets you compare raw byte sequences rather than canonicalising everything, which is no big deal in ASCII (just AND all letters with 0x20) but is intricate and fiddly in Unicode (hence lots of code and memory for all the esoteric rules required).
On a related note, I think filesystems should also be case-sensitive (like Unix, and unlike Windows and usually Mac OS X); if you want a helpful "ignore small differences" algorithm, it should happen at the user interface level, and it should be possible to override it, like the way you can put double quotes round a non-.txt filename in Notepad to prevent it from appending ".txt".
Being able to have "Letter.doc" and "letter.doc" in the same directory seems to me to be no more confusing than being able to have "Letter (21 Jan).doc" and "Letter [21 Jan].doc", or even "a_b", and "a__b" (for greater confusion, replace the underscores with spaces, but that wouldn't display properly in Slashcode). It's inconsistent to be sensitive to one small variation, but ignore another, particularly when the main principle of working with computers is "say exactly what you mean".
(I dislike extension hiding for the same reason; "you can't have two files with the same name, except when they're different types of file"? What sort of a silly rule is that?)
In Unrealscript (the Unreal engine's Java-ish scripting language), the same convention will work:
local Actor actor;
However, it's case-insensitive and recognises from context whether you mean a class or a variable (classes and variables effectively have separate namespaces), so you can actually do
local Actor Actor;
and that'll still work.
It can be annoying when trying to write Unreal Tournament mods in x86 Linux (compiling under Wine, testing in the native version of UT), since a lot of the source files are named with inconsistent case (the usual convention is InitialCapitalsOnWords, but not always).
IMO case-sensitivity is much nicer than case-insensitivity; in the Java standard library, distinguishing between SomeUnwieldyThingWithManyWords (a class) and someUnwieldyThingWithManyWords (a variable) can be hard, but if your class and instance names are a more sensible length (a couple of words) there's a big visual difference in something like "shortName = new ShortName()".
My current weapon of choice is Python, in which you can get away with very short generic names:
from hypothetical.xmllib import Parser parser = Parser()
and if there happens to be a clash, it's no big problem:
from hypothetical.xmllib import Parser from hypothetical.richtext import Parser as RTFParser # an instance of hypothetical.xmllib.Parser: parser = Parser() # an instance of hypothetical.richtext.Parser: rtfParser = RTFParser()
(of course, for legibility you might use XMLParser and xmlParser instead of Parser and parser, unless you're using the XML parser all the time and the RTF parser very little).
Rogue Spear works like that too (presumably also other Rainbow 6-series games like Ghost Recon). It's great for tension and twitchiness, but it makes the style of the game completely different - in something like CS you can do Arnie-style heroics after taking quite a few shots, but in Rogue Spear you'll be lucky to survive more than a couple of submachine gun bullets, and that's when you're armoured. As a result, you tend to be very cautious indeed.
(Amusingly, this attention to realism also means that the array of weapons the game offers is fairly redundant for the single player campaign, since you can pretty much just take the assault rifle of your choice if your opponents are wearing lots of armour, and silenced MP5s otherwise. The finer points of which SMG is better are pretty irrelevant when they're all accurate and will all kill unarmoured targets in one shot.)
Word 2000 can "round-trip"* well-formed XML - they claim it's HTML, but it's actually something HTMLish in XML (basically XHTML with the wrong namespace), plus Office and Word extensions in their own namespaces for the word-processor-ish stuff. As far as I remember, Word 2000 HTML supports a pretty large subset of the features Word 2000.doc files do.
A few years ago, Burger King (a British fast-food chain) ran an ad campaign about how their burgers were bigger than Big Macs, with a slogan something like "50% more meat than theM" (where the M was the Macdonalds "arches" logo). I seem to remember there was a bit of small print at the bottom, but nothing major.
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?
(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
With an efficient enough filesystem (ReiserFS?) you could do something like this:
(extra linebreaks for clarity)
# What is the name of customer #001? $ cat/tables/CUSTOMER/001/name
Joe Bloggs
# Who ordered order#003? $ cat/tables/ORDER/003/customer
001
# What is the name of the customer who ordered order#003? $cat/tables/CUSTOMER/$(</tables/ORDER/003/customer)/na me
003
The difficult bits of a relational database are the data integrity bits (transactions, atomic updates, that sort of thing), which *would* need extra filesystem support.
- registry (at least the windows do it currently): it's like the 777 version of/etc
I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.
IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?
If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?
(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
With an efficient enough filesystem (ReiserFS?) you could do something like this:
(extra linebreaks for clarity)
# What is the name of customer #001? $ cat/tables/CUSTOMER/001/name
Joe Bloggs
# Who ordered order#003? $ cat/tables/ORDER/003/customer
001
# What is the name of the customer who ordered order#003? $cat/tables/CUSTOMER/$(- registry (at least the windows do it currently): it's like the 777 version of/etc
I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.
IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?
If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).
Exactly. If I can find one, I always apply a no-CD crack to any game I install.
Back in the days of 3GB hard disks and smallish games, when you installed a couple of hundred megabytes and streamed the music, video and some of the sound from the CDs (see: Jedi Knight), it was reasonable to have to put the CD in the drive before playing.
Now that games don't let you play from the CD, partly for performance reasons and partly because the game is on several CDs anyway (like Unreal Tournament 2003 and its 3 CDs, of which about 2.5 CDs of data are copied to the hard disk and the last half a CD consists of optional mod tools and Linux binaries), I don't see any reason why I should be required to dig out the correct CD every time I play the game, just to reassure the game that I have a legal copy of it.
The Students' Union here implements this to elect officers (there's an extra "candidate" called RON, for "Re-open Nominations"). If Ron wins (rarely happens), nominations for candidates have to be reopened.
(People sometimes even campaign on Ron's behalf, when they realise the only candidate is someone who would do the job badly, and they want nominations reopened so they can stand for it themselves...)
A certificate is so named, because the signer has CERTIFIED the holder to be trustworthy.
You'd think so, wouldn't you? Unfortunately for the sanity of anyone using a certificate architecture, you're wrong.
The certificates issued by Verisign and other Certifying Authorities are more "proof of ID" than anything else; the CA makes no assertions about the trustworthiness of the owner, they just assert that the public encryption key you've just been sent belongs to the same people who own the server you're connecting to.
A typical CA certificate as used in SSL, translated into English:
"We hereby certify that the following RSA key [...] belongs to the owner of shopping.example.com. Signed, Verisign."
When your browser connects to https://shopping.example.com, the server sends you its certificate, and the browser checks Verisign's signature on that certificate. If the server proceeds to steal your credit card number, subscribe you to undesirable mailing lists, etc., that's between you and example.com; it's only Verisign's fault if it turns out they issued a wrong certificate.
PGP uses the same principle: when you sign someone else's key, the statement you're "signing" is something like this:
"The following public encryption key [...] belongs to Joe Bloggs ; I have met Joe and verified the photo on his passport. Signed, pclminion."
GnuPG (and probably PGP) never talks about certificates, only about signatures.
If that certificate is later used to commit a felony, say, credit card fraud, then YOU could be held legally liable, because YOU CERTIFIED that this guy was trustworthy. You were negligent in failing to find out that he wasn't.
The only way you could be held responsible is if it turns out that you were so sloppy about checking Joe Bloggs' ID that you were actually negligent; (i.e. didn't check it at all, or accepted an obviously fake form of ID, or something); in most jurisdictions digital signatures aren't legally binding anyway.
Anyway, this is what the trust mechanism in PGP is for.
[Digression: You can build up a "web of trust" by saying things like:
- I trust [... some people...] so if one of them says he's confirmed Joe Bloggs' identity, that's good enough for me; (full trust)
- these other people: [...] I don't trust so much, but if three different people all say they've confirmed Joe's identity, I'll believe that they're not all conspiring against me, so that's OK too; (partial trust)
- everyone else either I don't know, or I know but don't trust, so I'll ignore what they say when I make my decisions.
(These trust values are a private decision, there's no reason to reveal them to the world.)
end digression]
If you incorrectly sign someone's key, and a third party gets hurt as a result, you could easily argue that it's that third party's fault for trusting your opinion.
Incidentally, you can emulate the "certifying authority" model in PGP by giving full trust to Verisign, Thawte et al, and no trust to anyone else. This is a painfully limiting model compared with the full web of trust, though; to me it looks as though the whole mechanism was designed to make money for certifying authorities.
I don't think they would include a complete copy of currency at all (and if I'm not mistaken, it's illegal to do so unless the image is 50% smaller, or 150% larger than an actual bill.)
What does that mean in a digital-image context, in which image sizes are determined by resolution, anyway? How many pixels are there across a US dollar?
And yes, I've tried to write an ext3 driver for W2K. Now I'm not knocking MS specifically, but it clearly shows that they never thought anybody would like to do somethign this.
If you were knocking MS specifically, depending on your level of conspiracy theory, you might even think it shows the opposite:-)
"When I was working for a major global firm, and we dealt with small closed source development companies, we always had code escrow agreements. If the vendor went out of business or dropped support of the product, we had the ability to get the source and support it ourselves."
... and with open source, whatever happens, you have that same ability, with no need for an extra agreement.
The computer I'm typing this comment on is a Mac, which dual-boots Mac OS X (native filesystems: HFS+, UFS) and Linux (native filesystems: ext[23], XFS, ReiserFS). Neither OS had stable read/write support for the other's filesystems at the time I installed, but everything can write VFAT, so I allocated a 20GB VFAT (FAT32) filesystem (~/Storage in Linux,/Volumes/STORAGE in MacOS) for bulk file storage that should be shared between OSs.
(Linux supposedly now has reliable read/write HFS+ support, but I haven't tried it yet; if it is indeed reliable, I might migrate/home and ~/Storage onto HFS+, if I can work out how to keep UIDs in sync between the two OSs.)
The same solution would be useful on a dual-boot WinNT/Linux PC (NTFS vs...), although in this case VFAT has the additional advantage that it's the "second-best" filesystem for NT anyway.
(In fact, my PC still dual-boots Win98/Linux, so NTFS isn't an option for me anyway - I might consider upgrading to whatever the latest version is when a lot of software starts to require NT, or I might just run Linux and MacOS exclusively.)
In response to (a vocal minority of) players whining, Raven Software tweaked the game balance (force powers, lightsabre moves) in each released patch for JK2. Since they overreacted to perceived problems, the result was that the "overpowered" force powers and techniques became completely underpowered in the next patch.
Since the Debian security advisory says the bug was found by Andrew Morton in September, my guess is that it was fixed in 2.4.23 as an ordinary bug, but nobody realised it was an exploitable security hole until a day or two ago.
That only affects non-secure protocols. Admittedly, most Linux distributions helpfully do a net-install over unsecure http through a possibly untrusted gateway, which *is* a potential hole (imagine a gateway that transparently rewrote http requests to replace, say, RPMs or Debian packages with trojanned ones). As far as I know, both Red Hat and Debian are working on signed package infrastructures to counteract this problem, but neither is really there yet.
If you always use authenticated protocols with man-in-the-middle attack prevention via pre-shared host keys (SSH, IPSec, SSL, or downloading PGP-signed files with a known key), getting routed through a compromised gateway is acceptable; assuming the owner of the gateway can't break the encryption on your protocol of choice, the worst case is that you just lose connectivity.
If I start using untrusted networks a lot, I intend to upgrade my web hosting account to have ssh access, for this reason.
Slashdot Mirror
I'll add my vote for a text installer here. I helped a friend install Debian on an old (and very weird) computer, and had some trouble getting X working; it turned out that his graphics card (3DLabs, I think?), unlike 99% of other PC graphics cards, didn't support VESA, the lowest-common-denominator standard for graphics. A card-specific video driver worked, text mode worked, but there was nothing in between.
I suspect that if the installer had tried to go into a VESA framebuffer mode (like just about every other x86 Linux installer does), we'd never have got it installed in the first place.
[If it's not obvious: italic text comes from the parent post, which has already been modded into oblivion.]
;-)
I like Debian because it works on my Powerbook (big-endian non-x86 architecture with slightly odd hardware) just as well as it does on my (ordinary, mainstream) PC, and because it also managed to work on my friend's mutant box-of-bits (Cyrix 500MHz cheap-knock-off CPU, ancient AT keyboard port, USB mouse due to no PS/2 ports, serial and parallel ports on an expansion card, graphics card that didn't do VESA... the thing was extremely dodgy).
I also like
- the fact that the packages are made by control freaks (in the nicest possible sense of the words...) who care about consistency and things working nicely together to a sufficient extent that they have formal policies for large classes of packages, but package things in such a way that you can apply local hacks if you don't like how they did it, and make a great effort to preserve local changes to configuration
- the way the development process is usually as transparent and open as the source code of the packages themselves
- the fact that they've built a complete operating system out of software held to standards of freedom and openness high enough that even the Free Software Foundation's "Free Documentation License" doesn't qualify.
- the fact that no one entity controls Debian, so as long as someone's interested in developing for it, it won't go away
- the social contract that sets out the principles Debian will work by.
Debian sucks because
Debian rocks because
* Out dated packages, even in unstable
* Packages are tested (and compiled on more architectures than I care to imagine), and even unstable is actually usable
* Buggy and hard to use installer, people are told to use 3rd party installers because the developers cant be assed to fix it
* A text-mode installer which doesn't blithely assume that graphics mode works properly, or even that you *want* graphics mode (very handy if your hardware is bizarre, like my friend's old PC which couldn't do some of the standard VESA video modes)
* More security flaws than any other distro
[To parent: Really? Please provide links to back that up, I'm interested]
* A transparent mechanism for security updates and bulletins which doesn't introduce new and untested code at the same time, and takes all reported security flaws seriously
* Contains too many redundant and legacy apps
* Contains a huge choice of apps
* All the people who actually used Debian have fled to other distros such as Slackware, Gentoo and Fedora. Only the eleetist pricks are left now
* um... how to answer that one... how about "I actually use Debian, you insensitive clod?"
Mac OS X just works. It has applications that I need to get along. I like having some games. I like having stuff like iSync & iTunes. Yes, I know there's Linux apps, but I like how everything works *together* and isn't an ugly kludge.
That's fine, as long as the stuff that works *together* is all you need or want...
I think Linux has a loooong way to go as a desktop OS. The word from LinuxWorld was "It's not quite there yet.." which means that other people feel the same way.
The thing about "Linux On The Desktop" (tm) is that not everyone wants the same desktop. Most people without a programmer mindset would get frustrated by my usual desktop environment (at the moment, my window list consists of Firebird and 4 xterms - one of them is a MP3 player, one is my e-mail, two are sitting at shell prompts). On the other hand, I'd probably get frustrated by their desktop environment, on the basis that I couldn't get at my Unix shell. Linux is ready for *some people's* desktops, and it has been so for years.
Personally I think KDE's getting close to being usable by the "average computer user", if there is such a thing, and is way ahead in some ways. (I can't comment on Gnome, since I haven't used it since well before Gtk2.)
---- (Warning: this comment is an extended brain-dump.) ----
I bought a Powerbook as my primary computer, because I was sick of my Athlon's excessive and loud cooling system (2 case fans, PSU fan, CPU fan, 2 graphics card fans...), but also to give Mac OS X a go.
My choice was between a then-current (but getting old) 15" titanium Powerbook, or either getting a then-current 12" or 17" aluminium Powerbook or waiting for the 15" equivalent. It basically came down to: would I use Linux or Mac OS X? If I was happy in OS X, an AlBook would be better value (802.11g, Bluetooth, Firewire 800, lit keyboard, Geforce 4) but if I wanted to use Linux, the slightly older tech in a TiBook (802.11b, Firewire 400, ATi Radeon) would give me better compatibility. I went for the TiBook, and I'm really glad I did.
Mac OS X is a very nice OS - easy, reliable and pretty-looking - but for "hackability", give me a Free/open-source OS like Linux or a BSD any day. In Mac OS, yes, there's the underlying Darwin layer, but to do anything non-standard with it I'll have to "fight the system".
In Linux (Debian is my weapon of choice) I can just tell The System to get out of my way: on my laptop, I've disabled Debian's networking infrastructure, in favour of writing an ad-hoc networking script that copes better with changing locations, while integrating nicely with IPSec (I use IPSec to control access to my wireless access point, at the request of my college computing service, whose bandwidth it's using). It's inconsistent, it's an ugly kludge which I must tidy up one day, and it's *so* useful.
With its non-standard components (Netinfo being the main one), OS X takes a bit of getting used to for a Unix user; I'm still not entirely comfortable about having a network-accessible daemon holding my user info (I *think* it only listens on localhost, but I could be wrong...), and some of its features are a definite step backwards (any local user has access to crypted (not even MD5ed) passwords, a problem solved on every other Unix system by the introduction of shadow files).
I find some other things about Mac OS limiting: mostly just minor things, but things I'm accustomed to being able to change. The "window manager" (if you can call it that, since it appears to be integrated into the OS) is unconfigurable, which is great from a training point of view, but frustrating if you know what you're doing and want something like sloppy focus, or double-clicking on a title-bar doing something different (I like "window shading" (hiding the window and leaving only the title bar) myself), or whatever. The Dock is a nice shortcut for stuff, but I can't seem to change the icon for a disk image in the Dock in any obvious way (I've imaged my game CDs, so I ca
"Public source" seems to mean the header files to compile against, and the source code for the RTCW:ET-specific bits of the game (i.e. not the engine). This is the same sort of thing as the Half-Life SDK which the original (pre-commercial) Counterstrike was based on.
:-)
(For Debian users: if this was in Debian, it'd be a binary package called something like rtcw-enemyterritory-dev
As for the licensing (Polyp2000: thanks for posting the text), many game SDKs have restrictive EULA-like licenses (presumably the publishers insist on them) which mean that the majority of distributed mods for those games are likely technically illegal, as are many activities which an average gamer would probably consider perfectly reasonable.
In this case, among other things, the EULA asserts that you can't back up the SDK to a CD (only to "one (1)" hard disk), and that commercial distribution of a "New Creation" (mod) is not allowed (so magazines which distribute "RTCWstrike", or whatever the next big mod is called, on their cover CDs are potentially in trouble).
This isn't Free Software, it's not Open Source, and indeed the "non-commercial distribution" stipulation probably means it wouldn't even make it into Debian's non-free section.
As with any free hosting service with no minimum quality, mp3.com hosted a lot of talentless bands. However, there was a lot of good stuff there too: Neptune Crush, Misnomer (misnomer.co.uk), Cry, The Cynic Project, Soma, Swiv are some of the (former) mp3.com artists I liked.
Mathematical = to do with mathematics, of which maths is an abbreviation (USAians just abbreviate slightly further).
From the article:
(I don't think that should be possible, though... how can CD Wow be infringing copyright if they have nothing to do with the copying process used to make the CDs, but just buy and resell them?)
That's not ambiguity. Ambiguity is saying one thing which could mean several things; according to your assertion, case-sensitive languages have more than one way (Bar vs bar) to say the same thing.
English isn't case-insensitive, anyway. When you encounter a capital letter, it's telling you something (that it's the beginning of a sentence, or part of a title, or a proper noun,
There is a huge difference. In the "basic" Roman alphabet (with no accents or anything, as implemented in ASCII) there is a 1-to-1 mapping between upper and lower case; this isn't always true in general.
For instance, in German there is the "s-set" (which looks a lot like a lower-case beta), which is more or less interchangeable with the character pair "ss". It upper-cases to "SS" (i.e. there is no capital s-set). With that in mind, in a case insensitive Unicode-based language, how many of strasse, stra(s-set)e, STRASSE should be equivalent?
Once you've finished hard-coding your case comparison rules, what other equivalences are allowed? Is a-acute ("a" with an acute accent, which Slashcode doesn't seem to want to let me post) the same as "a", bearing in mind that both are conventionally upper-cased to A in French, and is the correct answer "if and only if the programmer is French"?
Being case-sensitive also lets you compare raw byte sequences rather than canonicalising everything, which is no big deal in ASCII (just AND all letters with 0x20) but is intricate and fiddly in Unicode (hence lots of code and memory for all the esoteric rules required).
On a related note, I think filesystems should also be case-sensitive (like Unix, and unlike Windows and usually Mac OS X); if you want a helpful "ignore small differences" algorithm, it should happen at the user interface level, and it should be possible to override it, like the way you can put double quotes round a non-.txt filename in Notepad to prevent it from appending ".txt".
Being able to have "Letter.doc" and "letter.doc" in the same directory seems to me to be no more confusing than being able to have "Letter (21 Jan).doc" and "Letter [21 Jan].doc", or even "a_b", and "a__b" (for greater confusion, replace the underscores with spaces, but that wouldn't display properly in Slashcode). It's inconsistent to be sensitive to one small variation, but ignore another, particularly when the main principle of working with computers is "say exactly what you mean".
(I dislike extension hiding for the same reason; "you can't have two files with the same name, except when they're different types of file"? What sort of a silly rule is that?)
In Unrealscript (the Unreal engine's Java-ish scripting language), the same convention will work:
local Actor actor;
However, it's case-insensitive and recognises from context whether you mean a class or a variable (classes and variables effectively have separate namespaces), so you can actually do
local Actor Actor;
and that'll still work.
It can be annoying when trying to write Unreal Tournament mods in x86 Linux (compiling under Wine, testing in the native version of UT), since a lot of the source files are named with inconsistent case (the usual convention is InitialCapitalsOnWords, but not always).
IMO case-sensitivity is much nicer than case-insensitivity; in the Java standard library, distinguishing between SomeUnwieldyThingWithManyWords (a class) and someUnwieldyThingWithManyWords (a variable) can be hard, but if your class and instance names are a more sensible length (a couple of words) there's a big visual difference in something like "shortName = new ShortName()".
My current weapon of choice is Python, in which you can get away with very short generic names:
from hypothetical.xmllib import Parser
parser = Parser()
and if there happens to be a clash, it's no big problem:
from hypothetical.xmllib import Parser
from hypothetical.richtext import Parser as RTFParser
# an instance of hypothetical.xmllib.Parser:
parser = Parser()
# an instance of hypothetical.richtext.Parser:
rtfParser = RTFParser()
(of course, for legibility you might use XMLParser and xmlParser instead of Parser and parser, unless you're using the XML parser all the time and the RTF parser very little).
Rogue Spear works like that too (presumably also other Rainbow 6-series games like Ghost Recon). It's great for tension and twitchiness, but it makes the style of the game completely different - in something like CS you can do Arnie-style heroics after taking quite a few shots, but in Rogue Spear you'll be lucky to survive more than a couple of submachine gun bullets, and that's when you're armoured. As a result, you tend to be very cautious indeed.
(Amusingly, this attention to realism also means that the array of weapons the game offers is fairly redundant for the single player campaign, since you can pretty much just take the assault rifle of your choice if your opponents are wearing lots of armour, and silenced MP5s otherwise. The finer points of which SMG is better are pretty irrelevant when they're all accurate and will all kill unarmoured targets in one shot.)
Word 2000 can "round-trip"* well-formed XML - they claim it's HTML, but it's actually something HTMLish in XML (basically XHTML with the wrong namespace), plus Office and Word extensions in their own namespaces for the word-processor-ish stuff. As far as I remember, Word 2000 HTML supports a pretty large subset of the features Word 2000 .doc files do.
(*: i.e. not just export like Word 97 did)
A few years ago, Burger King (a British fast-food chain) ran an ad campaign about how their burgers were bigger than Big Macs, with a slogan something like "50% more meat than theM" (where the M was the Macdonalds "arches" logo). I seem to remember there was a bit of small print at the bottom, but nothing major.
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
/tables/CUSTOMER/001/name
/tables/ORDER/003/customer
/tables/CUSTOMER/$(</tables/ORDER/003/customer)/na me
/etc
So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?
(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
With an efficient enough filesystem (ReiserFS?) you could do something like this:
(extra linebreaks for clarity)
# What is the name of customer #001?
$ cat
Joe Bloggs
# Who ordered order#003?
$ cat
001
# What is the name of the customer who ordered order#003?
$cat
003
The difficult bits of a relational database are the data integrity bits (transactions, atomic updates, that sort of thing), which *would* need extra filesystem support.
- registry (at least the windows do it currently): it's like the 777 version of
I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.
IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?
If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
/tables/CUSTOMER/001/name
/tables/ORDER/003/customer
/tables/CUSTOMER/$(- registry (at least the windows do it currently): it's like the 777 version of /etc
So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?
(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
With an efficient enough filesystem (ReiserFS?) you could do something like this:
(extra linebreaks for clarity)
# What is the name of customer #001?
$ cat
Joe Bloggs
# Who ordered order#003?
$ cat
001
# What is the name of the customer who ordered order#003?
$cat
I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.
IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?
If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).
Exactly. If I can find one, I always apply a no-CD crack to any game I install.
Back in the days of 3GB hard disks and smallish games, when you installed a couple of hundred megabytes and streamed the music, video and some of the sound from the CDs (see: Jedi Knight), it was reasonable to have to put the CD in the drive before playing.
Now that games don't let you play from the CD, partly for performance reasons and partly because the game is on several CDs anyway (like Unreal Tournament 2003 and its 3 CDs, of which about 2.5 CDs of data are copied to the hard disk and the last half a CD consists of optional mod tools and Linux binaries), I don't see any reason why I should be required to dig out the correct CD every time I play the game, just to reassure the game that I have a legal copy of it.
The Students' Union here implements this to elect officers (there's an extra "candidate" called RON, for "Re-open Nominations"). If Ron wins (rarely happens), nominations for candidates have to be reopened.
(People sometimes even campaign on Ron's behalf, when they realise the only candidate is someone who would do the job badly, and they want nominations reopened so they can stand for it themselves...)
A certificate is so named, because the signer has CERTIFIED the holder to be trustworthy.
...] so if one of them says he's confirmed Joe Bloggs' identity, that's good enough for me; (full trust)
You'd think so, wouldn't you? Unfortunately for the sanity of anyone using a certificate architecture, you're wrong.
The certificates issued by Verisign and other Certifying Authorities are more "proof of ID" than anything else; the CA makes no assertions about the trustworthiness of the owner, they just assert that the public encryption key you've just been sent belongs to the same people who own the server you're connecting to.
A typical CA certificate as used in SSL, translated into English:
"We hereby certify that the following RSA key [...] belongs to the owner of shopping.example.com. Signed, Verisign."
When your browser connects to https://shopping.example.com, the server sends you its certificate, and the browser checks Verisign's signature on that certificate. If the server proceeds to steal your credit card number, subscribe you to undesirable mailing lists, etc., that's between you and example.com; it's only Verisign's fault if it turns out they issued a wrong certificate.
PGP uses the same principle: when you sign someone else's key, the statement you're "signing" is something like this:
"The following public encryption key [...] belongs to Joe Bloggs ; I have met Joe and verified the photo on his passport. Signed, pclminion."
GnuPG (and probably PGP) never talks about certificates, only about signatures.
If that certificate is later used to commit a felony, say, credit card fraud, then YOU could be held legally liable, because YOU CERTIFIED that this guy was trustworthy. You were negligent in failing to find out that he wasn't.
The only way you could be held responsible is if it turns out that you were so sloppy about checking Joe Bloggs' ID that you were actually negligent; (i.e. didn't check it at all, or accepted an obviously fake form of ID, or something); in most jurisdictions digital signatures aren't legally binding anyway.
Anyway, this is what the trust mechanism in PGP is for.
[Digression: You can build up a "web of trust" by saying things like:
- I trust [... some people
- these other people: [...] I don't trust so much, but if three different people all say they've confirmed Joe's identity, I'll believe that they're not all conspiring against me, so that's OK too; (partial trust)
- everyone else either I don't know, or I know but don't trust, so I'll ignore what they say when I make my decisions.
(These trust values are a private decision, there's no reason to reveal them to the world.)
end digression]
If you incorrectly sign someone's key, and a third party gets hurt as a result, you could easily argue that it's that third party's fault for trusting your opinion.
Incidentally, you can emulate the "certifying authority" model in PGP by giving full trust to Verisign, Thawte et al, and no trust to anyone else. This is a painfully limiting model compared with the full web of trust, though; to me it looks as though the whole mechanism was designed to make money for certifying authorities.
I don't think they would include a complete copy of currency at all (and if I'm not mistaken, it's illegal to do so unless the image is 50% smaller, or 150% larger than an actual bill.)
What does that mean in a digital-image context, in which image sizes are determined by resolution, anyway? How many pixels are there across a US dollar?
And yes, I've tried to write an ext3 driver for W2K. Now I'm not knocking MS specifically, but it clearly shows that they never thought anybody would like to do somethign this.
:-)
If you were knocking MS specifically, depending on your level of conspiracy theory, you might even think it shows the opposite
The computer I'm typing this comment on is a Mac, which dual-boots Mac OS X (native filesystems: HFS+, UFS) and Linux (native filesystems: ext[23], XFS, ReiserFS). Neither OS had stable read/write support for the other's filesystems at the time I installed, but everything can write VFAT, so I allocated a 20GB VFAT (FAT32) filesystem (~/Storage in Linux, /Volumes/STORAGE in MacOS) for bulk file storage that should be shared between OSs.
/home and ~/Storage onto HFS+, if I can work out how to keep UIDs in sync between the two OSs.)
...), although in this case VFAT has the additional advantage that it's the "second-best" filesystem for NT anyway.
(Linux supposedly now has reliable read/write HFS+ support, but I haven't tried it yet; if it is indeed reliable, I might migrate
The same solution would be useful on a dual-boot WinNT/Linux PC (NTFS vs
(In fact, my PC still dual-boots Win98/Linux, so NTFS isn't an option for me anyway - I might consider upgrading to whatever the latest version is when a lot of software starts to require NT, or I might just run Linux and MacOS exclusively.)
In response to (a vocal minority of) players whining, Raven Software tweaked the game balance (force powers, lightsabre moves) in each released patch for JK2. Since they overreacted to perceived problems, the result was that the "overpowered" force powers and techniques became completely underpowered in the next patch.
Since the Debian security advisory says the bug was found by Andrew Morton in September, my guess is that it was fixed in 2.4.23 as an ordinary bug, but nobody realised it was an exploitable security hole until a day or two ago.
That only affects non-secure protocols. Admittedly, most Linux distributions helpfully do a net-install over unsecure http through a possibly untrusted gateway, which *is* a potential hole (imagine a gateway that transparently rewrote http requests to replace, say, RPMs or Debian packages with trojanned ones). As far as I know, both Red Hat and Debian are working on signed package infrastructures to counteract this problem, but neither is really there yet.
If you always use authenticated protocols with man-in-the-middle attack prevention via pre-shared host keys (SSH, IPSec, SSL, or downloading PGP-signed files with a known key), getting routed through a compromised gateway is acceptable; assuming the owner of the gateway can't break the encryption on your protocol of choice, the worst case is that you just lose connectivity.
If I start using untrusted networks a lot, I intend to upgrade my web hosting account to have ssh access, for this reason.