Not really. You would only want to use the GPL *IF* you agree with its morality(I do). What would otherwise be the reason, the cool name?
Functionality... we're talking about libraries here. The GPL says, roughly speaking, 'any code that uses this code must also be GPL.' So if you want to link against a GPL'd library you must GPL your code... or not use that library, which may mean rewriting all that functionality from scratch if the functionality is not otherwise available. The idea here in GPL'ing a library is that you -force- any apps that use the library to also be GPL. Making exceptions, obviously, counteracts that some...
The LGPL does not have this problem. IMHO, the LGPL rocks. LGPL is like the GPL but makes the exception that 'code that is only linked to this library is not considered to incorporate it' or words more or less to that effect.
If writing from scratch, I think I'd always release libraries LGPL and release apps BSD style.
Oh, yeah - Debian is biggest.
on
Which BSD?
·
· Score: 1
I'm not sure how much it's worth, since between alien and compiling from sources you can get whatever you want for any distribution, with more or less work, but still, it's nice to know there's so many official packages out there. Even if some of them (the Bible, the anarchy faq... ) are of dubious computing value...
Debian is technically superior to Redhat... meaning, it has better tech. Redhat, OTOH, is more well-rounded, not to mention that everybody and their dog packages in rpm format.
The basic difference comes down to the package formats... Debian packages have a package identity which can provide, conflict with, or depend on other packages - many of which are 'virtual packages' that don't exist (so you can have multiple packages that provide 'mailreader' or 'newsserver' or what have you, and plug-in replacements of one thing for another.) This allows (assuming proper debugging) for a beautiful automation of dependencies to the point that I can type 'apt-get install lyx' and it will go out and get for me (by ftp or from the cd) all the appropriate packages - libraries, TeX, LaTeX, LyX itself, and install them. (I'm not sure what it would do about X-windows and window managers and such since there are so many options there... probably issue a warning that you need to choose a package that provides xserver... )
It's also pretty good (though not as good as Slackware) at not getting in your way. You do run into a problem in that, if you want to compile from sources, then you also have to compile everything that depends on what you're compiling, to do it cleanly - though it is possible to cheat... I installed the SVGA X-server as a package and then just installed the Voodoo3 server over it (without package)... dependencies are all happy and the package system is none the wiser. But this is obviously risky, and any instability in X is my own fault now.
When the new release comes out I plan to do an 'apt-get upgrade' and have everything automagically replaced... though, I'll have to re-tweak the XServer and recompile my compiled apps.
Anyway... by contrast, Redhat does its packages and dependencies by filename. This is okay, especially if you only stick to official redhat packages and only upgrade the entire distribution. (I have a habit, in debian, of doing partial upgrading... upgrading some library so I can install some new program and then, of course, I need to upgrade all the things that depend on that library... I don't know how well that'd work in redhat.) I -think- that all this is mostly a philisophical difference in how to do things, without too much practical impact, at least right now. I also think Redhat currently has better install tools - but I don't use Redhat, so... maybe a redhat person can discuss their advantages.
Anyway, if you don't mind installing via command line client, debian is great. But... use dpkg on old debian systems or apt on new debian systems. Deselect was a nightmare.:o (Though you had to use it once for the base install... )
Right. So, in a nutshell, debian is really cool tech under a not-so-hot front end, and redhat is a really cool front-end over not-so-hot tech.
IMHO, YMMV, I am a Debian user, I was not paid for this statement.
I know how to stop it from happening, but I don't have the power to -do- so. Just get Linus &co. to add all the 'inferior' patches to the kernel and put them in as non-standard build options...
Build with SGI scalability extension (non-standard) [y/N]? Build with TurboLinux clustering extensions (non-standard) [y/N]?
Maybe give them their own 'non-standard extensions' section with warnings that enabling these extensions may break things, these extensions are not as thoroughly tested as the 'main' portion of the kernel, etc, etc.
It's not like there aren't unstable/experimental build options already.
Actually, almost every snack-food company will replace your snack if you send them the 'unused portion' of the offending food. Of course, if there's nothing -wrong- with it, this is kinda pointless, but if the pretzels (or whatever) are actually stale, yes, you can send it in and get a new one.
Terms like 'Cyberjacking' or 'Webjacking' have already been taken by the media for describing techniques of 'stealing' webhits - taking sitenames that are very similar and dumping false META tags in your code just to get search engine hits. So. Y'know, you can try it, but the mass media gets better exposure than a lone slashdotter.:)
Uh... there's been people working on Linux-on-Itanium for a while now, so, no matter what happens with Solaris, Linux will be running 64-bit on Itanium early on.
Who, might I ask, are geek girls supposed to find a date with? Ummm. I'd take a cue from Helen: Sweetheart of the Internet and go after the artistic type. Okay, so Spenser and Helen have their problems, but I still think it's a great idea! Artists and Geeks complement each other wonderfully... if they don't kill each other.:) The same logic goes for geek guys, too, of course, keeping an eye out for artist women. (Of course, if you think all art is worthless spouting of personal views in different mediums then this advice should not apply to you. OTOH, if you have something against worthless spouting of personal views, why are you reading slashdot?:))
Not -quite- as bad as some people seem to think (I think). My reading of this is:
We're patenting the idea of having a 'buy' button next to an item, where clicking the buy button is all you need to do to purchase the item.
As opposed to what many people seem to think which is that after doing your shopping-cart you click 'buy' and it recovers your information from the last time through. It -is- a -little- more innovative than that. Unfortunately, probably innovative enough to be completely valid.
Y2K is an entirely seperate issue and it didn't 'get passed' people. It's not a bug, it's a tradeoff... size for a 2 digit instead of a 4 digit year in exchange for failure in the year 2000. Nor is it universal. There are plenty of systems out there without a y2k problem.
However; A CPU's 'power' is the instructions it performs in a given amount of time. The only way to waste computational power is to spend some cycles not executing an instruction or to execute unnecessary instructions. So, which are you saying is happening? And what is your technique for harnessing this 'missing' 99% of our power?
If there's no floppy, sure, replace the boot-rom. Or pull the hard-drive and put it in a machine that -does- have a floppy.
An encrypted OS is a cleverer idea, but it has to be implemented carefully. Now that I've broken physically into the lab and copied and/or taken the hard-drive I can take my time cracking the encryption. The initial authentication had better be stronger than 8 letters.
If the machine can be booted up without authentication, I take off the case, replace the CPU with an ICE, and read/write directly to memory to bypass security. If you can't trust the integrity of memory, you're sunk. If it can't be booted up without authentication, well, that's awfully inconvenient. But it is more secure.
Better yet... if you want your machine to be secure from physical attack, secure it physically. 'cause -nothing- is going to stop a DoS attack if the cracker gets physical access. It'll take hardly any amount of explosive at all for that...
You support the notion that you can do anything on an 8088 that you can do on a PentiumIII with no loss of performance simply by writing the software more efficiently?
This is the idea that I am contesting. The idea that we are only using 1% of our CPU power.
Granted wordprocessing leaves the machine idle. So does booting it up, setting it to never start a screen saver, and not launching any applications. Or just playing solitaire. In these cases, you're just sitting around waiting for user input and then doing a little bit of drawing.
But I contest the notion that there is a hidden 99% of our power that is not being used because of poor coding practices.
If this were true in the Windows case, wouldn't a Linux that utilizes the CPU fully be 100 times more powerful than Windows? And can you honestly say that Linux -is- 100 times more powerful than Windows? I certainly wouldn't, not in the benchmarking sense, anyway.
You're right, that I didn't understand that you didn't say anything about the hard drive. I didn't understand -what- you were saying was 'how we can protect our systems' but the hard drive was your most recent comment before that. As far as I can tell you've said nothing about security.
Next... a wait-looping program does -not- waste huge amounts of CPU. It wastes no more nor less than that processes share of CPU. Granted, wait-loops are inefficient, and it's better to explicitly relinquish the CPU with some sort of system call. However, this is not the same as 'wasting' 99% of the CPU power. Which, really, is the only point I'm taking issue with, here. It simply -is not true- that the CPU is 100 times more powerful than what we make use of. If it were, a rival operating system like Linux or BSD or SCO-Unixware or Solaris x86 would 'do it right' and be 100 times more powerful than Windows! That doesn't happen because we are not, even under Windows, wasting 99 percent of our CPU time.
Nor are the CPU meter utilities the only way that I've looked at CPU usage (although I disagree that they are inaccurate measures, but never mind that). I've used WinDbg on Windows and kdb on Unixware to step through various problems I was debugging, done various bits of profiling to test for real-time latencies, etc. We 'waste' at -most- ten percent of the CPU time doing context-switches, page-faults, and other OS tasks. I'm not making this stuff up, you know, there's plenty of literature on OS design that talks about these things. And honestly... don't you think it's a little bit arrogant of you to think you're the only person in the world who has noticed that we could get 100 times more out of our computers if only we 'did it right'? Do you really think OS designers are so blind as to have made that grievous an error?
First: You can put up to a meg memory on a 8088 without a card.
720K/1Meg... it isn't really a relevant difference. The point is that for the sorts of large calculations used in cryptography, 3d rendering, etc,... this isn't enough. A simple Xwindows running just a trivial window manager takes between 2 and 4 megs... you'd be thrashing your system before you even started an app!
Second: The level of the code you write, and your ability as a code writer indicate what you can make your machine do. You are wrong about what machines today utilize on their chip capability.
There are utilities for both windows and linux that show your percentage CPU usage. 2 or 3 percent is typical for an idle system, 90-something percent for an intensive videogame, maybe 50% for streaming video - bandwidth is usually the constraining factory here. Exact percentages vary from machine to machine, obviously... a PentiumI with a direct T1 connection is going to have different constraints than a Quad-Athlon machine with a 33.6 modem.:) At any rate, I regularly work with low-level code - driver/kernel level code, and standalone code - and I'm quite aware of what it takes to saturate a CPU. First- Ever try win3.1 on a pentium3? Wanna know why it runs better? The code can be excecuted better thru the CPU because of the CPUs capability.
Exactly. It is because the CPU was saturated, fully utilized, unable to perform any better, that a more powerful CPU allows the system to perform better. If, as you suggest, CPUs were massively under-utilized, then it wouldn't matter whether or not you had a more powerful CPU. To draw an analogy...
If I'm trying to drive to work on a 65 mph speed limit highway, if I'm driving a Mustang, I'm underutilizing the car, and upgrading to a Ferrari doesn't get me there any faster. (Unless I break the law. Ok, so it's a weak analogy).
If, OTOH, I'm driving a Model-T with a top speed of 45 mph... I'm fully utilized. Upgrading to a Mustang or a Ferrari -will- show improvement in my accomplishing the task.
What you're saying is equivalent to saying 'because upgrading from a Model-T to a Ferrari lets you go faster, this proves that we don't drive our Model-T's as fast as we could. If we wanted, we could drive them as fast as Ferraris!' It just doesn't make any sense.
-You can even use a weak HD and it runs better. If youve ever studied CPU architecture and how to program registers, you know this.
Sure. Hard drive has nothing to do with actual execution unless you start swapping. I don't see how this supports your point.
Second-this is the same way you can protect your machine against tampering. -...But as any good security expert, I will leave that a topic for another day.
I'm sorry, come again? Because hard drive speed is not a limiting factor on program execution time, we can secure our machines... how?
Third....WAY wrong with what is used today. In plain English, you are utilizing a 32 bit bus to process a 32 bit instruction that doesn't need to be 32 bit in length. it could be done in 8. Its called bloatware. Microsofts famous trademark. For proof, see above about registers.
Uhmmmm... no. Between caching, pipelining, branch prediction, and all that, this just isn't how it works. I'm no CPU architecture expert, but this violates even the basic principles. First of all, I believe the instructions themselves are still (mostly) 8bits. So a single bus fetch of 32 bits could fetch up to four instructions. Or an instruction and three bytes of arguments. Or whatever. Granted, I haven't studied the pentium archicture that thoroughly, but... when we went from 8->16 we did not go from 8 bit instructions to 16 bit instructions, nor did the 386 have 32 bit instructions. You will recall, please, that 8088 binary code runs on a pentium unchanged. Instructions are still 8 bits. More instructions are fetched per bus cycle with a larger CPU bus, not more memory wasted per instruction.
For an ISP, most of these problems go away, I think. There's increased vulnerability to man-in-the-middle attacks, but there are plenty of security protocols to deal with that.
You could, in theory anyway, use public key cryptography with good assurances... just issue your public key and your user's pre-generated private key to each new user with the rest of the install software...
If you could do it, actually, it'd be a really good idea for every session to be encrypted. Plaintext passwords over a phone line is one thing... theoretically vulnerable to man-in-the-middle interception, but not likely... over the air is another thing altogether. Anyone could be listening.
Uhm... no. I mean, in -principle- you're right, because of equivalence... any CPU powerful enough to be a Turing Machine can do anything any other CPU can. In theory. In practice... well, unlike the imaginary Turing machine, CPU's do not have an infinite amount of memory. If you take an ordinary 8088 and its motherboard, you just can't -have- more than 720K of memory. It's not possible. Now you -could- put some memory sockets on an ISA card and write a protocol to utilize that memory, etc, but a complete 8088 machine is limited by memory. With those memory limitations, it is not possible to perform calculations that take up more memory than that! Unless, of course, we use virtual memory... so... now, with disk-access speed memory, we write a Win95 Emulator (never mind the difficulties in context switching and utter lack of runtime security caused by the lack of a protected mode) and now we're off! We download and install Quake V (it's been a few years since we started this project, you see, a couple more versions came out) and run at... 1 frame per week. Maybe we try something less ambitious... printing out a pdf document... at one page every six hours.
No, I'm sorry, we utilize -much- more than 1% of our computing power in -many- everyday tasks, and what is theoretically 'possible' with older CPUs is -not- the same as what is feasible.
Besides which,... the security issues between 8088 and PentiumIII aren't the level of utilization, but the lack/existence of a protected mode, DMA transfers, bus protocols, etc. I'm not an expert, so I couldn't even start to tell you how we can be sure an OS is or is not secure against software taking advantage of hardware architecture. Obviously, -NO- OS is secure against actual tampering with the hardware directly. After all, the tamperer could always replace the OS with his own boot disk. But that, too, has little to do with the difference between 8088 and Pentium III...
Oops. Well, that's what I get for trusting a quick-n-dirty websearch for correct information, though you'd think somebody auctioning the book could transcribe the author correctly. Ah well. Philip K. Dick is an excellent author too, who needed some mention in this thread.:)
According to netcraft, www.eb.com... which is also the encyclopedia britannica... is running Netscape Enterprise Server on Solaris. I think it's a reasonable assumption that www.britannica.com is the same. This doesn't speak badly of Solaris or Netscape, IMO... it's just, that there's nothing quite so spectacularly useful to such a broad cross-section of the population as a free, on-line, high-quality encyclopedia. They may need to increase their capacity, oh... to about a thousand times what it was when they were a pay site.
William Gibson is a science fiction author, the first really successful cyberpunk author, but -hardly- the -first- cyberpunk author. The others, however - John Brunner, Walter Jon Williams, Bruce Sterling, etc, - might still be obscure if not for him, and I have little doubt that Pat Cadigan, Neal Stephenson and others were strongly influenced by his work.
He did -not- write The Sheep Look Up aka Blade Runner, that was John Brunner. Sheep is good, but not much related to the movie. Stand on Zanzibar is better, IMHO.
IMO, also, Gibson's only -really- good books - so far - are Neuromancer and Idoru. Those two are -well- worth reading. Count Zero revealed too much his lack of computer knowledge, Burning Chrome has some excellent stories in it, but much of it is what they call 'juvenalia'... stuff he wrote before he was a 'mature' author. Virtual Light was a good read but nothing stunning, a bit too predictable. Idoru, however, was excellent, and I very much look forward to this new book. I read, enjoyed, and own copies of and will re-read all his books, btw, so when I say 'really good' I mean as opposed to 'good' not as opposed to 'bad';)
At this point it probably doesn't really matter -that- much since both systems are good, but, debian has a package-based dependency system, not a file based dependency system, so problems like 'the libraries were there, the rpm just could find them' as mentioned in the review won't happen. If libc++2.8 is in the list of installed packages, it doesn't matter where it was installed.
Basically, the debian package system is more powerful, flexible, and reliable. It also, it must be admitted, has had some of the most godawful interfaces ever, but that's changing. The 'apt' system is pretty good, and works on the current 'stable' release and will be the standard installer on the next release.
With apt, basically... you type 'apt-get install ghostview' and it will download and install the ghostview, ghostscript, and whatever libraries they require. Or, 'apt-get install lyx' and it installs lyx, latex, tex, and the libraries they depend on. (Yes, it does ask you, with a tally of the total number of megs that you're installing, before doing this.)
Anyway. Debian has lots of technical and reliability advantages, as well as being the largest distribution, but, I'll freely admit it's not even -close- to being user friendly.:) It's also true that the theoretically 'better' package system hasn't had the hard test of being used by derivative distributions the way RPM's have, so there may be flaws that are hidden by that.
Anyway, I hope that one day we'll have a common package format that includes all the info of rpm and deb and any other package format out there, at which point the whole issue will become irrelevant, at least, as a matter of comparison between distributions.
Your little anti-communist rant misses the point that here in Ameri(c|k)a it's the gov't that's telling the phone companies that they -may not- charge per-minute, and that in Europe it's the -lack- of gov't intervention that allows the telcos to charge 'what the market will bear.'
Other than the lack of factual content, it was well designed for hitting emotional buttons and getting people worked up. If you include a little factual content in the future maybe you can bring about the New Red Scare, if that's really what you want to do. I can always move to Canada... or maybe Europe... if you succeed.
If you're going to go massively parallel, why branch predict at all? Admittedly I'm software, but I vaguely recall from my computer architecture class that the idea, at least, of calculating -both- branches (or all n^2 branches for deeper pipelines) was at least an idea, if not implemented widely yet. I suppose, though, that 'wasteful' archictectures like that won't be explored until we start to hit physics-induced limits on silicon, and people need -some- way to improve performance without increasing actual speed.
I completely agree. But here's a question: What constitutes a patentable intellectual property in software?
Any idea which is not 'obvious' to the patent reviewers... which is to say, any idea whatsover that hasn't already been patented. Some of these patents can be challenged in court, but most judges don't know any more than the patent reviewers about software.
I'm not even sure that I know what part of my code/products are patentable. Am I going to have to worry about companies swooping in and stealing my effort just because they had the resources to get the patent filled?
Ummmm. Maybe. Depends what you mean. If you and xyz, inc. invent something on the same day, and they patent it and you don't, you lose. If you invent it the day after, you very definitely lose.
OTOH, if you invent something and -tell the world- what you've invented, the day -before- xyz, inc. files for a patent, they can't, legally, touch you. (Or anyone, their patent is invalid by 'prior art').
The good news is that the open-source movement is a continual stream of prior-art being poured out into the world, so at least -the- most absurd patents from now on will be defeatable.
Anyway, what is 'patentable' is basically, algorithims and ways to combine algorithms for a purpose. (Despite the fact that arithmatical algorithms are not patentable, software algorithms are, even though the two are often (always?) interchangeable.)
Actually, I would pay $100 for Linux... I was seriously considering picking up 'coherent' or whatever the $100 unix-a-like was before Linux stormed the scene.
Anyway, a quick comparison...
1: Windows is a GUI running on top of DOS.
Linux w/Xwindows is a GUI running on top of, well, Linux.
2: Windows stores its system parameters in an easily corrupted and largely undocumented 'registry,' except when it stores them in an 'INI' file.
Linux stores its parameters in a scattering of thoroughly, if arcanely, documented text files.
3: Windows provides an point-and-click interface to some systems settings through the 'control panel,' and to other systems settings in a scattering of controls in the various desktop tools (see User Interface Hall of Shame).
Linux provides a variety of point-and-click interfaces to systems settings, depending on your distribution, KDE/Gnome/Window Manager choice, etc. I'm not really sure how mature any of these tools are since I don't use them, but we can give the point to Windows for the sake of argument.
4: Windows requires you to use the GUI/Mouse for many of the common operations.
Linux requires you to use the command line for many of the more obscure operations.
5: Windows has lots of useful commercial software, but little, and often poorly ported, freeware.
Linux has lots of useful freeware, but little, though usually properly ported, commercial software.
6: Windows crashes frequently.
Linux rarely crashes.
7: Windows is supported by hordes of trolls.
Linux is supported by hordes of flamers.
Summary: 1 is a tie, 2 is a marginal victory for Linux, 3 is a matter of preference, 4 is a matter of preference, 5 is a matter of preference, 6 is a clear victory for Linux, and 7 is a major blow to both sides.
Thank you, but your points are invalid and unsubstantiated, please move along.
The problem you're complaining about has little to do with installers (directly). The reason things don't 'just work' anymore is because of all that stuff hidden in the 'lib' directories... shared libraries, they have to match in version to the software or it won't work right. 'Installers' in windows deal with this by writing the 'correct' version of the.dll into the appropriate directory. This may then break other things. 'Installers' in linux, depending on your distribution, generally install -either- libraries or apps, and in the case of apps, check the versions of libraries (and other shared resources, drivers for example). If they don't line up, it balks and refuses to continue.
The 'solution' to this 'complexity' is to go back to static linking - or the modern variant, putting the shared libs in program-local directories, and not really 'sharing' them. The difficulty with this 'solution' is your 2meg program can becom a 100meg program mighty quick. IMHO, Windows has enough bloat and Linux doesn't need it, so I'll take the 'complexity' over the 'solution.' After all, the complexity was originally a solution to the bloating caused by repeated copies of the same code being linked into each program.
Slashdot Mirror
Not really. You would only want to use the GPL *IF* you agree with its morality(I do). What would otherwise be the reason, the cool name?
Functionality... we're talking about libraries here. The GPL says, roughly speaking, 'any code that uses this code must also be GPL.' So if you want to link against a GPL'd library you must GPL your code... or not use that library, which may mean rewriting all that functionality from scratch if the functionality is not otherwise available. The idea here in GPL'ing a library is that you -force- any apps that use the library to also be GPL. Making exceptions, obviously, counteracts that some...
The LGPL does not have this problem. IMHO, the LGPL rocks. LGPL is like the GPL but makes the exception that 'code that is only linked to this library is not considered to incorporate it' or words more or less to that effect.
If writing from scratch, I think I'd always release libraries LGPL and release apps BSD style.
I'm not sure how much it's worth, since between alien and compiling from sources you can get whatever you want for any distribution, with more or less work, but still, it's nice to know there's so many official packages out there. Even if some of them (the Bible, the anarchy faq... ) are of dubious computing value...
Debian is technically superior to Redhat... meaning, it has better tech. Redhat, OTOH, is more well-rounded, not to mention that everybody and their dog packages in rpm format.
... )
... dependencies are all happy and the package system is none the wiser. But this is obviously risky, and any instability in X is my own fault now.
:o
The basic difference comes down to the package formats... Debian packages have a package identity which can provide, conflict with, or depend on other packages - many of which are 'virtual packages' that don't exist (so you can have multiple packages that provide 'mailreader' or 'newsserver' or what have you, and plug-in replacements of one thing for another.) This allows (assuming proper debugging) for a beautiful automation of dependencies to the point that I can type 'apt-get install lyx' and it will go out and get for me (by ftp or from the cd) all the appropriate packages - libraries, TeX, LaTeX, LyX itself, and install them. (I'm not sure what it would do about X-windows and window managers and such since there are so many options there... probably issue a warning that you need to choose a package that provides xserver
It's also pretty good (though not as good as Slackware) at not getting in your way. You do run into a problem in that, if you want to compile from sources, then you also have to compile everything that depends on what you're compiling, to do it cleanly - though it is possible to cheat... I installed the SVGA X-server as a package and then just installed the Voodoo3 server over it (without package)
When the new release comes out I plan to do an 'apt-get upgrade' and have everything automagically replaced... though, I'll have to re-tweak the XServer and recompile my compiled apps.
Anyway... by contrast, Redhat does its packages and dependencies by filename. This is okay, especially if you only stick to official redhat packages and only upgrade the entire distribution.
(I have a habit, in debian, of doing partial upgrading... upgrading some library so I can install some new program and then, of course, I need to upgrade all the things that depend on that library... I don't know how well that'd work in redhat.) I -think- that all this is mostly a philisophical difference in how to do things, without too much practical impact, at least right now. I also think Redhat currently has better install tools - but I don't use Redhat, so... maybe a redhat person can discuss their advantages.
Anyway, if you don't mind installing via command line client, debian is great. But... use dpkg on old debian systems or apt on new debian systems. Deselect was a nightmare.
(Though you had to use it once for the base install... )
Right. So, in a nutshell, debian is really cool tech under a not-so-hot front end, and redhat is a really cool front-end over not-so-hot tech.
IMHO, YMMV, I am a Debian user, I was not paid for this statement.
I know how to stop it from happening, but I don't have the power to -do- so.
Just get Linus &co. to add all the 'inferior' patches to the kernel and put them in as non-standard build options...
Build with SGI scalability extension (non-standard) [y/N]?
Build with TurboLinux clustering extensions (non-standard) [y/N]?
Maybe give them their own 'non-standard extensions' section with warnings that enabling these extensions may break things, these extensions are not as thoroughly tested as the 'main' portion of the kernel, etc, etc.
It's not like there aren't unstable/experimental build options already.
Actually, almost every snack-food company will replace your snack if you send them the 'unused portion' of the offending food. Of course, if there's nothing -wrong- with it, this is kinda pointless, but if the pretzels (or whatever) are actually stale, yes, you can send it in and get a new one.
Terms like 'Cyberjacking' or 'Webjacking' have already been taken by the media for describing techniques of 'stealing' webhits - taking sitenames that are very similar and dumping false META tags in your code just to get search engine hits. So. Y'know, you can try it, but the mass media gets better exposure than a lone slashdotter. :)
Uh... there's been people working on Linux-on-Itanium for a while now, so, no matter what happens with Solaris, Linux will be running 64-bit on Itanium early on.
Who, might I ask, are geek girls supposed to find a date with? :) The same logic goes for geek guys, too, of course, keeping an eye out for artist women. (Of course, if you think all art is worthless spouting of personal views in different mediums then this advice should not apply to you. OTOH, if you have something against worthless spouting of personal views, why are you reading slashdot? :))
Ummm. I'd take a cue from Helen: Sweetheart of the Internet and go after the artistic type. Okay, so Spenser and Helen have their problems, but I still think it's a great idea! Artists and Geeks complement each other wonderfully... if they don't kill each other.
Not -quite- as bad as some people seem to think (I think). My reading of this is:
We're patenting the idea of having a 'buy' button next to an item, where clicking the buy button is all you need to do to purchase the item.
As opposed to what many people seem to think which is that after doing your shopping-cart you click 'buy' and it recovers your information from the last time through. It -is- a -little- more innovative than that. Unfortunately, probably innovative enough to be completely valid.
IMHO, IANAL
Y2K is an entirely seperate issue and it didn't 'get passed' people. It's not a bug, it's a tradeoff... size for a 2 digit instead of a 4 digit year in exchange for failure in the year 2000. Nor is it universal. There are plenty of systems out there without a y2k problem.
However; A CPU's 'power' is the instructions it performs in a given amount of time. The only way to waste computational power is to spend some cycles not executing an instruction or to execute unnecessary instructions. So, which are you saying is happening? And what is your technique for harnessing this 'missing' 99% of our power?
If there's no floppy, sure, replace the boot-rom. Or pull the hard-drive and put it in a machine that -does- have a floppy.
An encrypted OS is a cleverer idea, but it has to be implemented carefully. Now that I've broken physically into the lab and copied and/or taken the hard-drive I can take my time cracking the encryption. The initial authentication had better be stronger than 8 letters.
If the machine can be booted up without authentication, I take off the case, replace the CPU with an ICE, and read/write directly to memory to bypass security. If you can't trust the integrity of memory, you're sunk. If it can't be booted up without authentication, well, that's awfully inconvenient. But it is more secure.
Better yet... if you want your machine to be secure from physical attack, secure it physically. 'cause -nothing- is going to stop a DoS attack if the cracker gets physical access. It'll take hardly any amount of explosive at all for that...
Okay... let me get this straight:
You support the notion that you can do anything on an 8088 that you can do on a PentiumIII with no loss of performance simply by writing the software more efficiently?
This is the idea that I am contesting. The idea that we are only using 1% of our CPU power.
Granted wordprocessing leaves the machine idle. So does booting it up, setting it to never start a screen saver, and not launching any applications. Or just playing solitaire. In these cases, you're just sitting around waiting for user input and then doing a little bit of drawing.
But I contest the notion that there is a hidden 99% of our power that is not being used because of poor coding practices.
If this were true in the Windows case, wouldn't a Linux that utilizes the CPU fully be 100 times more powerful than Windows? And can you honestly say that Linux -is- 100 times more powerful than Windows? I certainly wouldn't, not in the benchmarking sense, anyway.
You're right, that I didn't understand that you didn't say anything about the hard drive. I didn't understand -what- you were saying was 'how we can protect our systems' but the hard drive was your most recent comment before that. As far as I can tell you've said nothing about security.
Next... a wait-looping program does -not- waste huge amounts of CPU. It wastes no more nor less than that processes share of CPU. Granted, wait-loops are inefficient, and it's better to explicitly relinquish the CPU with some sort of system call. However, this is not the same as 'wasting' 99% of the CPU power.
Which, really, is the only point I'm taking issue with, here. It simply -is not true- that the CPU is 100 times more powerful than what we make use of. If it were, a rival operating system like Linux or BSD or SCO-Unixware or Solaris x86 would 'do it right' and be 100 times more powerful than Windows! That doesn't happen because we are not, even under Windows, wasting 99 percent of our CPU time.
Nor are the CPU meter utilities the only way that I've looked at CPU usage (although I disagree that they are inaccurate measures, but never mind that). I've used WinDbg on Windows and kdb on Unixware to step through various problems I was debugging, done various bits of profiling to test for real-time latencies, etc. We 'waste' at -most- ten percent of the CPU time doing context-switches, page-faults, and other OS tasks. I'm not making this stuff up, you know, there's plenty of literature on OS design that talks about these things. And honestly... don't you think it's a little bit arrogant of you to think you're the only person in the world who has noticed that we could get 100 times more out of our computers if only we 'did it right'? Do you really think OS designers are so blind as to have made that grievous an error?
First: You can put up to a meg memory on a 8088 without a card.
... this isn't enough. A simple Xwindows running just a trivial window manager takes between 2 and 4 megs... you'd be thrashing your system before you even started an app!
:)
720K/1Meg... it isn't really a relevant difference. The point is that for the sorts of large calculations used in cryptography, 3d rendering, etc,
Second: The level of the code you write, and your ability as a code writer indicate what you can make your machine do. You are wrong about what machines today utilize on their chip capability.
There are utilities for both windows and linux that show your percentage CPU usage. 2 or 3 percent is typical for an idle system, 90-something percent for an intensive videogame, maybe 50% for streaming video - bandwidth is usually the constraining factory here. Exact percentages vary from machine to machine, obviously... a PentiumI with a direct T1 connection is going to have different constraints than a Quad-Athlon machine with a 33.6 modem.
At any rate, I regularly work with low-level code - driver/kernel level code, and standalone code - and I'm quite aware of what it takes to saturate a CPU.
First- Ever try win3.1 on a pentium3? Wanna
know why it runs better? The code can be excecuted better thru the CPU because of the CPUs capability.
Exactly. It is because the CPU was saturated, fully utilized, unable to perform any better, that a more powerful CPU allows the system to perform better. If, as you suggest, CPUs were massively under-utilized, then it wouldn't matter whether or not you had a more powerful CPU. To draw an analogy...
If I'm trying to drive to work on a 65 mph speed limit highway, if I'm driving a Mustang, I'm underutilizing the car, and upgrading to a Ferrari doesn't get me there any faster. (Unless I break the law. Ok, so it's a weak analogy).
If, OTOH, I'm driving a Model-T with a top speed of 45 mph... I'm fully utilized. Upgrading to a Mustang or a Ferrari -will- show improvement in my accomplishing the task.
What you're saying is equivalent to saying 'because upgrading from a Model-T to a Ferrari lets you go faster, this proves that we don't drive our Model-T's as fast as we could. If we wanted, we could drive them as fast as Ferraris!'
It just doesn't make any sense.
-You can even use a weak HD and it runs better. If youve ever studied CPU architecture and how to program registers, you know this.
Sure. Hard drive has nothing to do with actual execution unless you start swapping. I don't see how this supports your point.
Second-this is the same way you can protect your machine against tampering. -...But as any good security expert, I will leave that a topic for another day.
I'm sorry, come again? Because hard drive speed is not a limiting factor on program execution time, we can secure our machines... how?
Third....WAY wrong with what is used today. In plain English, you are utilizing a 32 bit bus to process a 32 bit instruction that doesn't need to be 32 bit in length. it could be done in 8. Its called bloatware. Microsofts famous trademark. For proof, see above about registers.
Uhmmmm... no. Between caching, pipelining, branch prediction, and all that, this just isn't how it works. I'm no CPU architecture expert, but this violates even the basic principles. First of all, I believe the instructions themselves are still (mostly) 8bits. So a single bus fetch of 32 bits could fetch up to four instructions. Or an instruction and three bytes of arguments. Or whatever. Granted, I haven't studied the pentium archicture that thoroughly, but... when we went from 8->16 we did not go from 8 bit instructions to 16 bit instructions, nor did the 386 have 32 bit instructions. You will recall, please, that 8088 binary code runs on a pentium unchanged. Instructions are still 8 bits. More instructions are fetched per bus cycle with a larger CPU bus, not more memory wasted per instruction.
For an ISP, most of these problems go away, I think. There's increased vulnerability to man-in-the-middle attacks, but there are plenty of security protocols to deal with that.
You could, in theory anyway, use public key cryptography with good assurances... just issue
your public key and your user's pre-generated private key to each new user with the rest of the install software...
If you could do it, actually, it'd be a really good idea for every session to be encrypted. Plaintext passwords over a phone line is one thing... theoretically vulnerable to man-in-the-middle interception, but not likely... over the air is another thing altogether. Anyone could be listening.
Uhm... no. I mean, in -principle- you're right, because of equivalence... any CPU powerful enough to be a Turing Machine can do anything any other CPU can. In theory.
... the security issues between 8088 and PentiumIII aren't the level of utilization, but the lack/existence of a protected mode, DMA transfers, bus protocols, etc. I'm not an expert, so I couldn't even start to tell you how we can be sure an OS is or is not secure against software taking advantage of hardware architecture.
In practice... well, unlike the imaginary Turing machine, CPU's do not have an infinite amount of memory. If you take an ordinary 8088 and its motherboard, you just can't -have- more than 720K of memory. It's not possible.
Now you -could- put some memory sockets on an ISA card and write a protocol to utilize that memory, etc, but a complete 8088 machine is limited by memory.
With those memory limitations, it is not possible to perform calculations that take up more memory than that!
Unless, of course, we use virtual memory... so... now, with disk-access speed memory, we write a Win95 Emulator (never mind the difficulties in context switching and utter lack of runtime security caused by the lack of a protected mode) and now we're off! We download and install Quake V (it's been a few years since we started this project, you see, a couple more versions came out) and run at... 1 frame per week.
Maybe we try something less ambitious... printing out a pdf document... at one page every six hours.
No, I'm sorry, we utilize -much- more than 1% of our computing power in -many- everyday tasks, and what is theoretically 'possible' with older CPUs is -not- the same as what is feasible.
Besides which,
Obviously, -NO- OS is secure against actual tampering with the hardware directly. After all, the tamperer could always replace the OS with his own boot disk. But that, too, has little to do with the difference between 8088 and Pentium III...
Oops. Well, that's what I get for trusting a quick-n-dirty websearch for correct information, though you'd think somebody auctioning the book could transcribe the author correctly. Ah well. Philip K. Dick is an excellent author too, who needed some mention in this thread. :)
According to netcraft, www.eb.com ... which is also the encyclopedia britannica ... is running Netscape Enterprise Server on Solaris.
I think it's a reasonable assumption that www.britannica.com is the same. This doesn't speak badly of Solaris or Netscape, IMO... it's just, that there's nothing quite so spectacularly useful to such a broad cross-section of the population as a free, on-line, high-quality encyclopedia. They may need to increase their capacity, oh... to about a thousand times what it was when they were a pay site.
William Gibson is a science fiction author, the first really successful cyberpunk author, but -hardly- the -first- cyberpunk author. The others, however - John Brunner, Walter Jon Williams, Bruce Sterling, etc, - might still be obscure if not for him, and I have little doubt that Pat Cadigan, Neal Stephenson and others were strongly influenced by his work.
... stuff he wrote before he was a 'mature' author. Virtual Light was a good read but nothing stunning, a bit too predictable. Idoru, however, was excellent, and I very much look forward to this new book. I read, enjoyed, and own copies of and will re-read all his books, btw, so when I say 'really good' I mean as opposed to 'good' not as opposed to 'bad' ;)
His previous books are:
Neuromancer, Count Zero, Burning Chrome, Virtual Light, Idoru.
He did -not- write The Sheep Look Up aka Blade Runner, that was John Brunner. Sheep is good, but not much related to the movie. Stand on Zanzibar is better, IMHO.
IMO, also, Gibson's only -really- good books - so far - are Neuromancer and Idoru. Those two are -well- worth reading. Count Zero revealed too much his lack of computer knowledge, Burning Chrome has some excellent stories in it, but much of it is what they call 'juvenalia'
At this point it probably doesn't really matter -that- much since both systems are good, but, debian has a package-based dependency system, not a file based dependency system, so problems like 'the libraries were there, the rpm just could find them' as mentioned in the review won't happen. If libc++2.8 is in the list of installed packages, it doesn't matter where it was installed.
:) It's also true that the theoretically 'better' package system hasn't had the hard test of being used by derivative distributions the way RPM's have, so there may be flaws that are hidden by that.
Basically, the debian package system is more powerful, flexible, and reliable. It also, it must be admitted, has had some of the most godawful interfaces ever, but that's changing. The 'apt'
system is pretty good, and works on the current 'stable' release and will be the standard installer on the next release.
With apt, basically... you type 'apt-get install ghostview' and it will download and install the ghostview, ghostscript, and whatever libraries they require. Or, 'apt-get install lyx' and it installs lyx, latex, tex, and the libraries they depend on. (Yes, it does ask you, with a tally of the total number of megs that you're installing, before doing this.)
Anyway. Debian has lots of technical and reliability advantages, as well as being the largest distribution, but, I'll freely admit it's not even -close- to being user friendly.
Anyway, I hope that one day we'll have a common package format that includes all the info of rpm and deb and any other package format out there, at which point the whole issue will become irrelevant, at least, as a matter of comparison between distributions.
Your little anti-communist rant misses the point that here in Ameri(c|k)a it's the gov't that's telling the phone companies that they -may not- charge per-minute, and that in Europe it's the -lack- of gov't intervention that allows the telcos to charge 'what the market will bear.'
Other than the lack of factual content, it was well designed for hitting emotional buttons and getting people worked up. If you include a little factual content in the future maybe you can bring about the New Red Scare, if that's really what you want to do. I can always move to Canada... or maybe Europe... if you succeed.
If you're going to go massively parallel, why branch predict at all? Admittedly I'm software, but I vaguely recall from my computer architecture class that the idea, at least, of calculating -both- branches (or all n^2 branches for deeper pipelines) was at least an idea, if not implemented widely yet. I suppose, though, that 'wasteful' archictectures like that won't be explored until we start to hit physics-induced limits on silicon, and people need -some- way to improve performance without increasing actual speed.
I completely agree. But here's a question: What constitutes a patentable intellectual property in software?
Any idea which is not 'obvious' to the patent reviewers... which is to say, any idea whatsover that hasn't already been patented. Some of these patents can be challenged in court, but most judges don't know any more than the patent reviewers about software.
I'm not even sure that I know what part of my code/products are patentable. Am I going to have to worry about companies swooping in and stealing my effort just because they had the resources to get the patent filled?
Ummmm. Maybe. Depends what you mean. If you and xyz, inc. invent something on the same day, and they patent it and you don't, you lose. If you invent it the day after, you very definitely lose.
OTOH, if you invent something and -tell the world- what you've invented, the day -before- xyz, inc. files for a patent, they can't, legally, touch you. (Or anyone, their patent is invalid by 'prior art').
The good news is that the open-source movement is a continual stream of prior-art being poured out into the world, so at least -the- most absurd patents from now on will be defeatable.
Anyway, what is 'patentable' is basically, algorithims and ways to combine algorithms for a purpose. (Despite the fact that arithmatical algorithms are not patentable, software algorithms are, even though the two are often (always?) interchangeable.)
Actually, I would pay $100 for Linux... I was
seriously considering picking up 'coherent' or whatever the $100 unix-a-like was before Linux stormed the scene.
Anyway, a quick comparison...
1:
Windows is a GUI running on top of DOS.
Linux w/Xwindows is a GUI running on top of, well, Linux.
2:
Windows stores its system parameters in an easily corrupted and largely undocumented 'registry,' except when it stores them in an 'INI' file.
Linux stores its parameters in a scattering of thoroughly, if arcanely, documented text files.
3:
Windows provides an point-and-click interface to some systems settings through the 'control panel,' and to other systems settings in a scattering of controls in the various desktop tools (see User Interface Hall of Shame).
Linux provides a variety of point-and-click interfaces to systems settings, depending on your distribution, KDE/Gnome/Window Manager choice, etc. I'm not really sure how mature any of these tools are since I don't use them, but we can give the point to Windows for the sake of argument.
4:
Windows requires you to use the GUI/Mouse for many of the common operations.
Linux requires you to use the command line for many of the more obscure operations.
5:
Windows has lots of useful commercial software, but little, and often poorly ported, freeware.
Linux has lots of useful freeware, but little,
though usually properly ported, commercial software.
6:
Windows crashes frequently.
Linux rarely crashes.
7:
Windows is supported by hordes of trolls.
Linux is supported by hordes of flamers.
Summary: 1 is a tie, 2 is a marginal victory for Linux, 3 is a matter of preference, 4 is a matter of preference, 5 is a matter of preference, 6 is a clear victory for Linux, and 7 is a major blow to both sides.
Thank you, but your points are invalid and unsubstantiated, please move along.
The problem you're complaining about has little to do with installers (directly). .dll into the appropriate directory. This may then break other things.
The reason things don't 'just work' anymore is because of all that stuff hidden in the 'lib' directories... shared libraries, they have to match in version to the software or it won't work right.
'Installers' in windows deal with this by writing the 'correct' version of the
'Installers' in linux, depending on your distribution, generally install -either- libraries or apps, and in the case of apps, check the versions of libraries (and other shared resources, drivers for example). If they don't line up, it balks and refuses to continue.
The 'solution' to this 'complexity' is to go back to static linking - or the modern variant, putting the shared libs in program-local directories, and not really 'sharing' them. The difficulty with this 'solution' is your 2meg program can becom a 100meg program mighty quick. IMHO, Windows has enough bloat and Linux doesn't need it, so I'll take the 'complexity' over the 'solution.' After all, the complexity was originally a solution to the bloating caused by repeated copies of the same code being linked into each program.