More specifically people who use linux, often don't like windows or Microsoft, so donating what $500 to this company for no good reason..?
Don't kid yourself.
If you doubt it, offer 2 or 3 random customers a $500 discount for the laptop without the windows licence. See how many don't care either way.
I'm not sure where you're getting your figures from, but I'm betting they're wrong. Let's say I'm Sharp or Dell, and I'm pushing 10,000 laptops a month onto the streets in the US. I don't know whether that figure is high or low, but it sounds good to me. Do you honestly think Microsoft is going to charge me $500 to install Windows onto each laptop, when I could just walk over to CompUSA and purchase the full copy of Windows XP for $200?
I don't know the exact figure, but this Windows tax is smaller than people make it out to be. They are not donating $500 to Microsoft.
There's nothing to be concerned about. lspci says:
nVidia Corporation NV17 [GeForce4 440 Go 64M] (rev a3)
As for maximum resolution, it's so low because basically it's using half the available pixels to go to the left eye and the other half to go to the right. Naturally, that is going to decrease the maximum resolution.
The Dell D800 has a similar ridiculous max resolution.
That option is still available to you. You could purchase this machine from Sharp, download your favorite Linux distribution, and then spend a while tracking down all the proper drivers and config file tweaks. In the end, you have saved money but have spent your time. It's a matter of which you have more of and which you are more willing to spend.
But if you're a big company, you probably don't care about a couple hundred bucks. The time and the guarantee of someone being on the phone is more important. Having some of your employees hunt around on mailing lists or usenet is a less effective use of resources than calling up your supplier and making use of that support contract.
We don't HAVE to uninstall Windows. Customers who want to dual boot are more than welcome to. Customers who only want Linux can have that, but are advised that they will still have a Windows license. Simply put, at our volumes it is impossible to get machines from a big-name vendor without Windows. Hell, at most people's volumes this is impossible. Microsoft has very strong contracts with laptop suppliers.
But like I said, customers who want Linux only are advised they will still be paying for Windows because we have to. Almost none of them care, because they understand the situation.
Everything in a laptop is a tradeoff game. Want fancier graphics/more powerful CPU/wireless/faster hard drive? You're gonna pay for it in weight and power consumption. Want to lighten the machine a bit? You're gonna pay for that in display size and power consumption. This thing essentially has two video displays crammed on top of each other to provide the 3D effect, which really kills the battery life. But if the display is the most important aspect to you, you're probably going to toss it on a desk and plug it into the wall.
Yes it's a niche product, but not every piece of hardware can be good for every possible situation. If you want something with excellent battery life and is very lightweight, the Sharp MM20 or IBM X series are both good. The Dell X300 is pretty nice too.
You're not just paying for having Linux installed. You're paying for support - an actual human on the phone if the machine craps out, or someone to personally reply to your mail. It's also the research that went into making all the hardware work, tracking down drivers, etc.
What a lot of people don't understand here is that big companies, educational institutions, and research groups just don't care about the price. To them, the support, assurance that everything works, and time savings are worth the extra cost. What's $600 compared to the hourly rate of a guy in IT spending an entire week outfitting machines with Linux and verifying that they completely work? People who get their kicks sitting at home and banging on the machine until it works simply aren't the target market for a product like this.
If you need the hardware for scientific visualization or whatever, then yes it is worth the added price. If all you want is a laptop to toy around on, it's probably not worth it to you. It's all about the right tool for the job.
For the purposes of displaying images like this, no Dell laptop works just as well, because no Dell laptop has this feature.
No improvement over C? You must be joking. ML offers me so many things that programming in C just isn't fun anymore.
Garbage collection - ML is fully garbaged collected. This means you don't need to worry about making and then freeing your own memory. Right away, an entire class of potential bugs is done away with. Since you don't need to manage and debug memory problems, you get more done faster. Your code is cleaner because there's not all that memory error checking.
Module system - SML includes a very nice type system which promotes creating good interfaces, hiding the internal representations of data structures, and several of the other merits of OOP-style design.
Functional - Coding focuses mainly on writing lots of small functions which do one little thing, then combining up the results of those functions to get lots done. List operations are very common and easy (if you're familiar with Perl, things like map, grep, and so forth are used all over the place)
Strongly typed - ML is very strongly typed, and yet this doesn't get in the way at all. The ML compiler's type checker uses something called type inference. You don't need to decorate your program all over the place with types, because the compiler actually proves the types of everything based on how they're used. Because it is so strictly typed, the type checker will catch most of your bugs for you.
Polymorphic types - You can write a function that operates on a data structure, no matter what type of data is stored within the list. As long as all the types match each other, ML doesn't care what those types are.
Exceptions - SML includes an exception mechanism which makes it easy to catch error conditions and handle them appropriately.
Pattern matching - Data types can be very complex, including several different subtypes within one type. For instance, a tree type could contain several different types of data at the nodes. To reconcile this with the strong typing, there's something called pattern matching. Basically, you can write several versions of the same function which operate on the same basic type but each branch only gets called if the subtypes meet a certain pattern. This one's a bit hard to explain. You have to see it in action.
In my (limited) experience with ML, it makes it very easy to code. The code is dense, but readable. A small number of lines can get a lot of work done. And what's better - you'll never get a segmentation fault unlike C. If you can get your program past the type checker, then it's pretty much going to run. And if you've handled all your exceptions and made sure that there's no unmatched patterns, your program will basically always run. It's really a pleasure to code in - far more so than I've experienced with C.
This sort of thing should be punishable by death. They've taken perfectly good, classic NeXT hardware and dropped in the motherboard-of-the-week - hardware which will be obsolete and forgotten in six months. Along the way, they've reduced the already small supply of NeXT equipment that exists out there for those of us who like the machines. Thanks for keeping the costs of cubes up with stupid mods like this, guys.
In my dealings with DEBs, they consist of two things: (1) a series of control files that have been tarred up (control.tar or control.tar.gz, I believe) and (2) all the actual contents of the package laid out in a filesystem (data.tar or data.tar.gz). These two files are then catted together into an archive using the ar program to form the finalized package.
I believe that this would then fail your definition of a package, since it's really just an archive with a wrapper around it.
I'm sure that Debian packgers have a much more thorough explanation, but this is what information I have figured out from blowing a few apart.
Interesting that you mention that... an RPM is simply a cpio archive with a really big header stuck to the top of it. A DEB is two tarballs stuck together using ar. A TGZ is a tarball with embedded control scripts.
If you're going to call a Slackware package a "source archive with a wrapper", then you're going to have to say the same thing about the other two systems as well.
...but it doesn't stay up to date like RedHat or Mandrake does.
Well, I don't think that's a valid assessment at all. Looking through the -current tree (last updated on Sunday evening), we've got X-4.0.3, gcc-2.95.3, the 2.2.19 kernel, Apache-1.3.19, Perl-5.6.1, Bash-2.05, and glibc-2.2.2... not to mention the piles of other programs that have recieved updates. Slackware 7.2 will probably be the most current distribution around when it is released.
Just because you don't hear about the updates everywhere doesn't mean they aren't getting done. The ChangeLog is your friend for things like this.
Yes, this is understandable. If you look through the forums on the site, you will see several threads about the PayPal account. Patrick has mentioned it several times. We don't want to make an announcement on the from of the site, because then it's going to look like some official Slackware Company thing, and we don't want anyone to be able to claim a chunk of it.
So basically, I cannot really do anything on Slashdot to prove that the account really goes to the distribution. I can tell you that Patrick himself set it up, after quite a lengthy email exchange with the rest of us. All I can do is give you my word that it's legit. If you'd like to email me privately to discuss this, feel free.
Due to *lots* of user inquiries and requests, we have set up a PayPal account for the Slackware core team members. It's been set up with the email address of paypal@slackware.com. Any donations recieved there will go straight to supporting the Slackware project - no companies are going to be taking a cut of this.
So if you're looking for a way to help us out, this is a good opportunity. Of course, buying the next release would also be helpful. But for those of you that download it or are just feeling generous, here's your chance. Thanks.
You're only saying there's no package managing system because that's what people have told you. Fact is, there's utilities to install, upgrade, remove, and create your own packages. There are command-line utilities to do all of the above, as well as pkgtool if you want a dialog interface.
These utilities have existed in Slackware since the beginning. Just because there's no dependancy tracking doesn't mean that there's no packaging system. Supporters of Slackware (me included) would tell you that the lack of dependancy tracking is a feature -- something best left to the system administrator to handle.
So please, be a little more informed about your subject before you shoot your mouth off. It's perfectly reasonable to say: "There's no Slackware packages because their system requires dependancy tracking, and Slackware doesn't do that." It's not reasonable to say: "There's no packaging system to speak of." That's just completely untrue.
Most of the time, ldconfig is automagically run for you. When you install new libraries onto a running system, the "make install" almost always runs ldconfig. When you install libraries from packages, the packaging system usually runs ldconfig for you.
While none of those methods are really automatic from the viewpoint of the operating system handling it for you, the end result to the users is the same. Libraries are magically dealt with.
The only times you ever really run ldconfig are if there's a broken "make install", you're doing something really complicated, or you are in exceedingly deep shit.
Slackware has an open development model. Any changes Patrick makes to the distribution are uploaded to our primary ftp server into the -current tree. This tree is the developmental branch for what will eventually become the next release.
If you walk through the changelog, you will note that -current is just about as open as it gets. We've made changes only to retract those changes days later because they didn't quite work. How many other distributions hang their development out in the open like that?
Yes, Debian does too. But to imply that Slackware does not have an open development model is wrong.
Slackware has always had a packaging system. The addition of an (unsupported) automatic upgrading utility is NOT the addition of a packaging system. The automatic upgrader only works to determine what has changed within the distribution and download those changes for you. The package utilities handle manipulating the packages.
Check out a Slackware system and look at installpkg, removepkg, and upgradepkg, among others.
The problem isn't with the distributions. It's with the GNU Project. GNU has made it very well known that they do not support man pages at all - only their info pages. Check out the top of most any man page from a GNU program and you will see something like this:
The information in this man page is an extract from the full documentation of the GNU C compiler, and is limited to the meaning of the options.
This man page is not kept up to date except when volunteers want to maintain it. If you find a discrepancy between the man page and the software, please check the Info file, which is the authoritative documentation.
The man page then proceeds to only contain a long listing of simple descriptions of the options. Some are even worse. Since the majority of any distribution's software comes from GNU, they have to deal with their lack of supplied man pages.
In general, man pages come from non-GNU programs or from people who write pages for those GNU programs that lack man pages. In my opinion, man is far superior to info, and I believe that the GNU project is doing everyone a disservice by keeping such poor man pages (or a complete lack of them altogether).
The only thing I don't like about Slack is that a few useful packages are not available - like docbook. Installing docbook by hand is not a trivial matter.
A full set of SGML tools including the DocBook DTDs are included in the/contrib section of Slackware 7.1. Enjoy!
If I wrote a unix shell script that grepped through a user's home directory for email addresses and then used sendmail to propagate itself to those people, it would be very very similar to the love bug.
Yes, except first you would have to view the attachment, save it to a file, and run it yourself. Given all those steps, you would more than likely figure out what it's doing and not actually run it.
For starters, don't write makefiles that assume things like -D486 for compile flags. That is incredibly annoying for scripting builds. Or if you absolutely feel the need for such flags, make sure that you can detect architecture and have the option for an appropriate flag (like -DEV6 on certain Alphas.
Also, if you're going to deal with bitwise operations, remember that some machines are big endian and some are little endian. You'll probably need to write different operations for each type.
Finally, Alphas, UltraSPARCs, and some other machines are 64-bit systems. Intel is 32-bit. That will get you into trouble at times.
Doesn't handle switching between runlevels well? How do you figure? There's an rc file for each runlevel, and switching between them causes the appropriate file to get run.
Probably the most common thing is going from multiuser to singleuser. Doing so will cause various services to be killed off, leaving only what is necissary running. When you jump back into multiuser mode, the rc.M file will get run, bringing all the network daemons and such back up.
Everything that needs starting and stopping is listed in the runlevel scripts. How is this not handling things well?
Slashdot Mirror
More specifically people who use linux, often don't like windows or Microsoft, so donating what $500 to this company for no good reason..? Don't kid yourself. If you doubt it, offer 2 or 3 random customers a $500 discount for the laptop without the windows licence. See how many don't care either way.
I'm not sure where you're getting your figures from, but I'm betting they're wrong. Let's say I'm Sharp or Dell, and I'm pushing 10,000 laptops a month onto the streets in the US. I don't know whether that figure is high or low, but it sounds good to me. Do you honestly think Microsoft is going to charge me $500 to install Windows onto each laptop, when I could just walk over to CompUSA and purchase the full copy of Windows XP for $200?
I don't know the exact figure, but this Windows tax is smaller than people make it out to be. They are not donating $500 to Microsoft.
That option is still available to you. You could purchase this machine from Sharp, download your favorite Linux distribution, and then spend a while tracking down all the proper drivers and config file tweaks. In the end, you have saved money but have spent your time. It's a matter of which you have more of and which you are more willing to spend.
But if you're a big company, you probably don't care about a couple hundred bucks. The time and the guarantee of someone being on the phone is more important. Having some of your employees hunt around on mailing lists or usenet is a less effective use of resources than calling up your supplier and making use of that support contract.
We don't HAVE to uninstall Windows. Customers who want to dual boot are more than welcome to. Customers who only want Linux can have that, but are advised that they will still have a Windows license. Simply put, at our volumes it is impossible to get machines from a big-name vendor without Windows. Hell, at most people's volumes this is impossible. Microsoft has very strong contracts with laptop suppliers.
But like I said, customers who want Linux only are advised they will still be paying for Windows because we have to. Almost none of them care, because they understand the situation.
Everything in a laptop is a tradeoff game. Want fancier graphics/more powerful CPU/wireless/faster hard drive? You're gonna pay for it in weight and power consumption. Want to lighten the machine a bit? You're gonna pay for that in display size and power consumption. This thing essentially has two video displays crammed on top of each other to provide the 3D effect, which really kills the battery life. But if the display is the most important aspect to you, you're probably going to toss it on a desk and plug it into the wall.
Yes it's a niche product, but not every piece of hardware can be good for every possible situation. If you want something with excellent battery life and is very lightweight, the Sharp MM20 or IBM X series are both good. The Dell X300 is pretty nice too.
You're not just paying for having Linux installed. You're paying for support - an actual human on the phone if the machine craps out, or someone to personally reply to your mail. It's also the research that went into making all the hardware work, tracking down drivers, etc.
What a lot of people don't understand here is that big companies, educational institutions, and research groups just don't care about the price. To them, the support, assurance that everything works, and time savings are worth the extra cost. What's $600 compared to the hourly rate of a guy in IT spending an entire week outfitting machines with Linux and verifying that they completely work? People who get their kicks sitting at home and banging on the machine until it works simply aren't the target market for a product like this.
If you need the hardware for scientific visualization or whatever, then yes it is worth the added price. If all you want is a laptop to toy around on, it's probably not worth it to you. It's all about the right tool for the job.
For the purposes of displaying images like this, no Dell laptop works just as well, because no Dell laptop has this feature.
In my (limited) experience with ML, it makes it very easy to code. The code is dense, but readable. A small number of lines can get a lot of work done. And what's better - you'll never get a segmentation fault unlike C. If you can get your program past the type checker, then it's pretty much going to run. And if you've handled all your exceptions and made sure that there's no unmatched patterns, your program will basically always run. It's really a pleasure to code in - far more so than I've experienced with C.
This sort of thing should be punishable by death. They've taken perfectly good, classic NeXT hardware and dropped in the motherboard-of-the-week - hardware which will be obsolete and forgotten in six months. Along the way, they've reduced the already small supply of NeXT equipment that exists out there for those of us who like the machines. Thanks for keeping the costs of cubes up with stupid mods like this, guys.
In my dealings with DEBs, they consist of two things: (1) a series of control files that have been tarred up (control.tar or control.tar.gz, I believe) and (2) all the actual contents of the package laid out in a filesystem (data.tar or data.tar.gz). These two files are then catted together into an archive using the ar program to form the finalized package.
I believe that this would then fail your definition of a package, since it's really just an archive with a wrapper around it.
I'm sure that Debian packgers have a much more thorough explanation, but this is what information I have figured out from blowing a few apart.
Interesting that you mention that... an RPM is simply a cpio archive with a really big header stuck to the top of it. A DEB is two tarballs stuck together using ar. A TGZ is a tarball with embedded control scripts.
If you're going to call a Slackware package a "source archive with a wrapper", then you're going to have to say the same thing about the other two systems as well.
Well, I don't think that's a valid assessment at all. Looking through the -current tree (last updated on Sunday evening), we've got X-4.0.3, gcc-2.95.3, the 2.2.19 kernel, Apache-1.3.19, Perl-5.6.1, Bash-2.05, and glibc-2.2.2... not to mention the piles of other programs that have recieved updates. Slackware 7.2 will probably be the most current distribution around when it is released.
Just because you don't hear about the updates everywhere doesn't mean they aren't getting done. The ChangeLog is your friend for things like this.
Yes, this is understandable. If you look through the forums on the site, you will see several threads about the PayPal account. Patrick has mentioned it several times. We don't want to make an announcement on the from of the site, because then it's going to look like some official Slackware Company thing, and we don't want anyone to be able to claim a chunk of it.
So basically, I cannot really do anything on Slashdot to prove that the account really goes to the distribution. I can tell you that Patrick himself set it up, after quite a lengthy email exchange with the rest of us. All I can do is give you my word that it's legit. If you'd like to email me privately to discuss this, feel free.
Due to *lots* of user inquiries and requests, we have set up a PayPal account for the Slackware core team members. It's been set up with the email address of paypal@slackware.com. Any donations recieved there will go straight to supporting the Slackware project - no companies are going to be taking a cut of this.
So if you're looking for a way to help us out, this is a good opportunity. Of course, buying the next release would also be helpful. But for those of you that download it or are just feeling generous, here's your chance. Thanks.
You're only saying there's no package managing system because that's what people have told you. Fact is, there's utilities to install, upgrade, remove, and create your own packages. There are command-line utilities to do all of the above, as well as pkgtool if you want a dialog interface.
These utilities have existed in Slackware since the beginning. Just because there's no dependancy tracking doesn't mean that there's no packaging system. Supporters of Slackware (me included) would tell you that the lack of dependancy tracking is a feature -- something best left to the system administrator to handle.
So please, be a little more informed about your subject before you shoot your mouth off. It's perfectly reasonable to say: "There's no Slackware packages because their system requires dependancy tracking, and Slackware doesn't do that." It's not reasonable to say: "There's no packaging system to speak of." That's just completely untrue.
Most of the time, ldconfig is automagically run for you. When you install new libraries onto a running system, the "make install" almost always runs ldconfig. When you install libraries from packages, the packaging system usually runs ldconfig for you.
While none of those methods are really automatic from the viewpoint of the operating system handling it for you, the end result to the users is the same. Libraries are magically dealt with.
The only times you ever really run ldconfig are if there's a broken "make install", you're doing something really complicated, or you are in exceedingly deep shit.
Slackware has an open development model. Any changes Patrick makes to the distribution are uploaded to our primary ftp server into the -current tree. This tree is the developmental branch for what will eventually become the next release.
If you walk through the changelog, you will note that -current is just about as open as it gets. We've made changes only to retract those changes days later because they didn't quite work. How many other distributions hang their development out in the open like that?
Yes, Debian does too. But to imply that Slackware does not have an open development model is wrong.
Slackware has always had a packaging system. The addition of an (unsupported) automatic upgrading utility is NOT the addition of a packaging system. The automatic upgrader only works to determine what has changed within the distribution and download those changes for you. The package utilities handle manipulating the packages.
Check out a Slackware system and look at installpkg, removepkg, and upgradepkg, among others.
In general, man pages come from non-GNU programs or from people who write pages for those GNU programs that lack man pages. In my opinion, man is far superior to info, and I believe that the GNU project is doing everyone a disservice by keeping such poor man pages (or a complete lack of them altogether).
A full set of SGML tools including the DocBook DTDs are included in the /contrib section of Slackware 7.1. Enjoy!
itself to those people, it would be very very similar to the love bug.
Yes, except first you would have to view the attachment, save it to a file, and run it yourself. Given all those steps, you would more than likely figure out what it's doing and not actually run it.
Executable email is just a stupid idea.
Also, if you're going to deal with bitwise operations, remember that some machines are big endian and some are little endian. You'll probably need to write different operations for each type.
Finally, Alphas, UltraSPARCs, and some other machines are 64-bit systems. Intel is 32-bit. That will get you into trouble at times.
Probably the most common thing is going from multiuser to singleuser. Doing so will cause various services to be killed off, leaving only what is necissary running. When you jump back into multiuser mode, the rc.M file will get run, bringing all the network daemons and such back up.
Everything that needs starting and stopping is listed in the runlevel scripts. How is this not handling things well?