Yes, the YaST ncurses interface is fully on par with the X-based version. You can even choose not to install the graphical version if you don't want it. The actual heavy lifting is shared, and the front-ends are only interfaces to use it.
The problem with this approach is that a lot of shops (including dealerships?) charge a "diagnostic fee" if you don't get the repair performed. This fee usually amounts to the per-hour fee of the mechanic performing the diagnostics. All in all, you'd likely end up spending the same amount as having them do all the work.:(
The only URLs that get sent to their servers are the ones that it's filtering out, ones that would normally exploit the bug. At the other end (granted, at least for now) is an IE-lookalike error message saying that the exploit was caught.
The first line before all that stuff involving redirection through their servers: if (NULL != strstr(dest,"\2") || NULL != strstr(dest,"\1") || NULL != strstr(dest,"\218"))
It only matches URLs containing %01, %02, or %8F, which doesn't really "fix" the problem, but it's at least a workaround.
I thought about this earlier today, and my guess is that IBM can only have so much leverage on SCO itself. However, if MS were to buy SCO, and continue the lawsuit, IBM could use all the leverage it has against MS.
As we've seen in the past, MS has tried to take on IBM on IP issues and IBM pointed to a number of infringing technologies that MS had, which stopped them in their tracks.
Re:How long has Compaq been making magnets?
on
Magnet Patent Suits
·
· Score: 2
Moreover, wouldn't this allow the company to sue multiple companies for the SAME "infringement"?
If they, for example, sue the manufacturer of the magnets, Seagate for using them in a disk, Compaq for using the "illegal" Seagate disks, and then sue Best Buy because they're selling Compaq equipment, wouldn't it follow that they'd be getting royalities four times for the same physical product and "instance" of infringement?
A rarity on Slashdot, it seems that this is actually a "legitmate" case of patent protection.
Slashdot has become quite accustomed to throwing their arms up in anger, and accusing others of not being good neighbors - but when the time comes for an open source project to be the good neighbor, what happens? We hear shouts of "well, they should have protected their trademark better." Damned if you do, damned if you don't.
Most of the "infringment" stories that Slashdot has seen are of the inflammatory nature. Many of them are projects that have nothing to do with one another, but here we have a different case.
The OpenSSH group is being asked by the project from whom their original code derived, and which group came up with the protocol they're implementing, to change their name. This isn't some monster corporation looking to quash competition. This is a small company which is receiving legitimate confusion about their product due to the success of a free implementation.
And when they ask the free implementation to change their name - the open source community scoffs. IMO, the open source community isn't being a very good neighbor.
Really, what's lost with a name change? Do the executables need to be renamed, thus causing confusion for the user? NO A while ago, when Sun first came out with what is now known as NIS, it was called Yellow Pages (yp). I believe it was British Telecom who held the trademark for the "Yellow Pages" name, and Sun was forced to change the name of their product. Did it cause confusion for the user? Maybe some initially, while people got acclimated to the new name in documentation, etc -- but the utilities, today, over 10 years later, still bear their original names of yp*. An earlier post mentioned other free projects creating symbolic links to the more widely known executable names, such as vim and elvis..
But even further, why must a project's name match the name of their executable? Apache installs httpd, not apached. (Ignoring windows, here). Samba installs [ns]mbd, not sambad. OpenSSH itself, as it is NOW doesn't install "opensshd".
All in all, I think the Open Source community needs to be a good neighbor here. This is more than a case of name usage, this is a case of a coder developing one of the most widely used pieces of software on the 'net. For better or worse, he chose to take it and make money with it, changing his license in the process. Should this negate the fact that the earlier code was out there? That he put the effort in to coming up with the protocol as well? I certainly don't think so.
Really, it doesn't take much effort to change the name of newly released products, and I don't think they're asking to change the millions of installed copies. All that would really be required is a new chosen name, and the registration of an appropriate domain.
Who knows, by being good neighbors, SSH Communications might even foot the bill for it.
Mostly because for the desktop systems, there's no hacking needed.
I have a dual G4 tower that I only run Linux on (I develop on it.) I found that the one button mouse made it pretty difficult to work with. XFree86 supports "faking" multibutton mice, using the control/shift/option keys - but what happens if you need a combination that is already occupied by the "workaround?"
So, I just went out and bought myself two logitech optical USB mice (one for my development pc). There was no additional configuration required, it was just seen as having more buttons than a normal apple mouse.
Now, for laptops - that's a different story. I'm not familar with the internals of a powerbook, but I'd imagine that the trackpad is hardwired. I've seen USB trackballs that "clip" onto the side of the laptop so no desktop surface is needed. For the most part, I'd think that hacking a multi button trackpad into a laptop would be more trouble than it's worth -- besides, given the modular nature of desktops, it's easier to replace a $200 motherboard or a $50 mouse if you mess it up -- but I would want to replace a $3500 laptop whose warranty I just certainly voided.
Personally, I like this phrase: 2. Your behavior or the performance or failure of your equipment, facilities or applications;
So, if you piss them off (like keep calling for tech support, as mentioned in one of the complaints), they can just shut off your service, and it doesn't get covered by the 99.9% agreement.
I'm sure the uproar isn't just over the ability to remember another digit.
There's serious money involved in the switch, when companies have to reprint stationary, advertisements, business cards.. make sure their applications can handle longer phone numbers correctly.
Seriously, just think about how many times when you enter your phone number while ordering something, if you mistype it -- it tells you that it's formatted wrong. That's just a small example of code that needs to be changed.
You're points are valid, but unfortunatly don't apply here.
All the examples you've chosen are either processor architecture or device driver related. Most of the code that both of these classes use in the "core" of the OS are non-architecture dependant, and are coded for best general use.
Forking the kernel for "big iron" may be required because utilizing that many resources effectively requires different algorithms at the very core of the OS - scheduling, virtual memory, caching, etc.
The advantage to forking the kernel is the simpilicity in maintaining the code for either. However, the major disadvantage -- as seen with the BSD's -- is that features in either tree just end up getting implemented twice.
It's a tough question to answer, and both choices have major long term implications.
NOTE: I accidentally hit submit instead of preview, so a snippet of this comment was posted prematurely. Please moderate the original down into oblivion.
I've posted articles on the missing features of Linux for a while. Most of them seem to be beyond the search threshold that Slashdot offers.
Hopefully, when I get some free time, I'll get the chance to attempt an implementation of any one of these. In the meantime, however, other people may benefit from a bulletted list.:)
So, here goes: Some of the features below, when read, will obviously require special hardware to support them. However, the hardware is useless without proper operating system support. Remember that this post is addressing features that commercial UNIX has and Linux doesn't. The details for the average developer obtaining the appropriate hardware to develop for and test on is irrelevant to this discussion.
Advanced high availability clustering.
Many people, when they see the word "clustering" automatically think of Beowulf, get all defensive, and miss the point completely. Clustering, in this context, is a enterprise necessity. When there are thousands of users depending on mission critical applications, clustering is the way to go. I spent a week in California recently training on DEC's (gah, Compaq)
TruCluster product. Now, granted, DEC has had over a decade of practice on VMS clustering to implement this, but it's what clustering should be. The filesystems are shared, and the systems can redirect network I/O internally. The filesystems are shared, but still involve a "director" of sorts, a member of the cluster to coordinate access. This is not to be confused with NFS, because the individual cluster members can write to the disk directly, rather than proxied through the "director" node.
An advanced, multivolume, dynamically resizable, journaled filesystem
IBM's JFS (which I realize is being ported -- but vapor != implementation) and DEC's AdvFS both offer dynamically resizable, journalling filesystems. I'm not sure if JFS allows multiple volumes, but AdvFS does. Basically what this accomplishes is the ability to add and remove disks from a live filesystem as it is running.
Most people know the benefits of a journalling filesystem, but for those who don't: When your system is writing something to disk, even though the program you're using eventually boils down to calling a write() system call to get it done, the OS actually has to perform many steps. All a disk is capable of guarenteeing is a single atomic write of a single block. Now, if you're writing out a file, this consists of many block writes for the data, but also writes for the meta-data. Meta data is the stuff associated with files, such as timestamps, permissions, links, but also stuff that the user never sees that maintains filesystem integrity. If your system crashes, loses power, etc during the middle of a meta-data write, you can lose an entire filesystem. At the very least, you'll end up with a potentially lengthy fsck(8) when you reboot. A journally filesystem essentially uses a "staging" area, where all writes to disk are queued up -- also on disk. A file and associated meta data can be guarenteed to be written or not written -- but not half way. If the operation did not complete, the operation can be completed when the system comes back up. This is called a replay, and it uses the journal to do this. Filesystem recoveries take seconds, instead of minutes or even hours on huge filesystems. Going into more detail is really beyond the scope of this post, but you get the idea.
Dynamic hardware reconfiguration
On large systems, including mainframes and high end UNIX servers, you can remove and add hardware
including processors and memory while the system is up and running. Solaris, for example, offers the ability to shutdown processors in mid execution so you can remove and replace them. Some Dell servers, running Windows NT or Windows 2000 also allow this, and add the ability to add and remove PCI cards on-the-fly.
System auditing
One of the major features that many sites
require is system auditing. This is very much more that system logging. The major difference is that, for example, I can set up auditing on my Digital UNIX servers so that any time any user calls the "socket" system call, I have a record of it, which arguments where used, when it was called, and by whom. I can restrict things even further so that I only see the record when user "joebob" called socket(), etc.
Others.
There are other features that come to mind, beyond the scalability issues that the post I'm replying to mentioned, but I'm hungry, and want my dinner.:)
I hope this clears up some of the clouds surrounding this sort of thing. I noticed that my original post was moderated down by someone ambitious as a "troll", when in fact it was not meant to be one at all. One of the major weaknesses of the Linux/BSD/Open Source community, and this has been mentioned before by people more known to the public eye than myself, is the inablility to look at the faults. No OS, including Linux, is perfect. The ability to see the imperfections, the flaws, the faults, and the missing features is what can enable the Open Source community to improve their software even more. Turning a blind eye to real issues does nothing other than stoke the fires of corporate ignorance as well as being self-fulfilling FUD.
I've posted articles on the missing features of Linux for a while. Most of them seem to be beyond the search threshold that Slashdot offers.
Hopefully, when I get some free time, I'll get the chance to attempt an implementation of any one of these. In the meantime, however, other people may benefit from a bulletted list.:)
So, here goes:
Advanced high availability clustering.
Many people, when they see the word "clustering" automatically think of Beowulf, get all defensive, and miss the point completely. Clustering, in this context, is a enterprise necessity. When there are thousands of users depending on mission critical applications, clustering is the way to go. I spent a week in California recently training on
DEC's (gah, Compaq) TruCluster product. Now, granted, DEC has had over a decade of practice on VMS clustering to implement this, but it's what clustering should be.
While I realize that this may come as a shock, modern commercial UNIX platforms are no more a 30-year old system than Linux, FreeBSD, or anything of the ilk is.
The idea that UNIX hasn't evolved at all over the last thirty years isn't just wrong, it's a position dangerously close to ignorance for a computing professional to take.
Many of the features that Linux and the *BSD's still lack are features that have been standard in commercial UNIX for years. Even with the growing number of Linux servers out there hosting web sites, most major e-commerce sites out there aren't using it. In the enterprise computing arena, the competitors are mainframes, UNIX (solaris, digital unix, hp/ux, etc), and (unfortunately) Windows NT/2000. It's a battle that Linux simply isn't mature enough to take part in yet.
Now, this isn't to say that Linux won't get there -- far from it. Linux, with the freight train of momentum it's got these days, will probably have a comparable feature set in a few years. However, decisions aren't made on vapor -- they're made on what can be rolled in today.
Competition in the desktop arena is also an area where Linux is ill-suited to compete. Microsoft completely dominates this market, and for most users, Windows is it. At this point, Linux can't compare to the user friendliness that Windows provides. [*]
Now, I'm a UNIX geek -- I earn my living running enterprise UNIX servers. I've also been running Linux at home and on my workplace desktop since mid 1995. Professional decisions aren't made on personal preferences (unless the technology involved is comparable) -- they're based on usability and technical merits. Linux, at this point, is mostly suited for the technical users' desktop, or the low to low-midrange server market.
-Jeff
[*]: Technically - yes, stability is part of user friendliness, but for most desktop users it's not a primary concern.
Re:The joy of a tight labor market.
on
The LEGO Desk
·
· Score: 5
.. yeah, and that the case itself could interlock onto the desk surface.
Having lego drinking glasses and other such things would do wonders for desk neatness.. nothing could tip over!
Most VPN software packages aren't running over TCP/IP. From what I've seen, everything from Cisco-Cisco router tunnelling all the way to MS VPN software uses IP Protocol 47. (GRE/IP) In the case of MS's they also use a TCP/IP port (17xx something) to provide authentication.
Disallowing most VPNs would be as simple as blocking IP protocol 47 at their gateway router. Trivial. "gre deny any any" in Cisco's IOS parlance.
As a reminder (and not really related to the post I'm replying to), VPN != Masquerading, although many sites could "detect" masqueraded traffic simply by watching for a higher-than-normal use of ports over 60,000. Most network providers - even companies and schools - have network monitoring hardware. I've learned how to configure Netscout probes and software to show me information very similar to this.
IPsec is also used, but I'm not as familiar with the details of that.
-Jeff
Who is SuSE aimed at? Everyone!
on
SuSE 7.0
·
· Score: 5
I'm an advanced user, so my opinion of what might be good for a beginner is probably very skewed.
I've been running SuSE for a while now, since a co-worker of mine went to work for them. One of the major things that attracted me to it was that one of the install options is the ability to choose ReiserFS as your default (root) filesystem.
I first installed 6.3. Recently, I installed a new box with 6.4-eval (they call their downloaded versions evals). I'm not at all afraid of non-graphical installs - I've been installing commercial UNIX boxes over a serial console for years. I found myself very much impressed with the graphical configuration/installation that SuSE has going. It found my hardware, presented appropriate technical options [module params] if you wanted them, etc.
All in all, I think it's a perfect blend of easy-to-use, and the level of control that your typical UNIX geek wants. The configure scripts are well thought out, and centered around a core "/etc/rc.config" settings file - which you can edit yourself if you wish, or have YaST do it for you. ..and it comes with damn near everything, but doesn't install all the fluff unless you want it to.
They offer add-on packages that aren't really part of the distro because they're not really mature yet, such as XFree86 4.0, on their FTP site.
Furthermore, they're going from a release 6.4 to a 7.0. This isn't abnormal. Part of it may be version creep - but it really wouldn't surprise me if it does, in fact, merit a full version increment.
I've tried most of the major Linux distributions - and SuSE is the one I've stuck with.
Actually, many modern systems don't require that the filename match. They load libraries by library name, which can be embedded in the actual library.
Try moving libsomething.so to liboldsomething.so, and then doing an ldconfig. It will find the liboldsomething.so as libsomething.so.
...and as a reponse to the question above about library locations, the linux ld.so finds all the libraries for you, as long as you've placed the directories in your/etc/ld.so.conf. The location, so long as ld.so can find them, is irrelevant. What *is* relevant is the different compile options and versions that different distributions use in their install.
-Jeff
% man ld /-soname n -soname name When creating an ELF shared object, set the inter nal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker.
Slashdot Mirror
Ok, using a penguin for a mascot is one thing -- but a shithawk? Probably not the best message. :)
Actually, he's rocking a VT320. :)
SaX2 is LGPL, according to /usr/share/doc/packages/sax2/LICENCE
Yes, the YaST ncurses interface is fully on par with the X-based version. You can even choose not to install the graphical version if you don't want it. The actual heavy lifting is shared, and the front-ends are only interfaces to use it.
The problem with this approach is that a lot of shops (including dealerships?) charge a "diagnostic fee" if you don't get the repair performed. This fee usually amounts to the per-hour fee of the mechanic performing the diagnostics. All in all, you'd likely end up spending the same amount as having them do all the work. :(
But as the article mentions, there's no floppy controller on the board.
Check the code again.
The only URLs that get sent to their servers are the ones that it's filtering out, ones that would normally exploit the bug. At the other end (granted, at least for now) is an IE-lookalike error message saying that the exploit was caught.
The first line before all that stuff involving redirection through their servers:
if (NULL != strstr(dest,"\2") || NULL != strstr(dest,"\1") || NULL != strstr(dest,"\218"))
It only matches URLs containing %01, %02, or %8F, which doesn't really "fix" the problem, but it's at least a workaround.
I was under the impression that tariffs of this sort were getting redistributed to copyright holders, not the government.
I think it's that they don't want the people who run the polls to destroy the system while screaming, "PC LOAD LETTER, WHAT THE HELL IS THAT?"
:)
That's just my guess though.
I thought about this earlier today, and my guess is that IBM can only have so much leverage on SCO itself. However, if MS were to buy SCO, and continue the lawsuit, IBM could use all the leverage it has against MS.
As we've seen in the past, MS has tried to take on IBM on IP issues and IBM pointed to a number of infringing technologies that MS had, which stopped them in their tracks.
Moreover, wouldn't this allow the company to sue multiple companies for the SAME "infringement"?
If they, for example, sue the manufacturer of the magnets, Seagate for using them in a disk, Compaq for using the "illegal" Seagate disks, and then sue Best Buy because they're selling Compaq equipment, wouldn't it follow that they'd be getting royalities four times for the same physical product and "instance" of infringement?
A rarity on Slashdot, it seems that this is actually a "legitmate" case of patent protection.
-Jeff
Slashdot has become quite accustomed to throwing their arms up in anger, and accusing others of not being good neighbors - but when the time comes for an open source project to be the good neighbor, what happens? We hear shouts of "well, they should have protected their trademark better." Damned if you do, damned if you don't.
Most of the "infringment" stories that Slashdot has seen are of the inflammatory nature. Many of them are projects that have nothing to do with one another, but here we have a different case.
The OpenSSH group is being asked by the project from whom their original code derived, and which group came up with the protocol they're implementing, to change their name. This isn't some monster corporation looking to quash competition. This is a small company which is receiving legitimate confusion about their product due to the success of a free implementation.
And when they ask the free implementation to change their name - the open source community scoffs. IMO, the open source community isn't being a very good neighbor.
Really, what's lost with a name change? Do the executables need to be renamed, thus causing confusion for the user? NO A while ago, when Sun first came out with what is now known as NIS, it was called Yellow Pages (yp). I believe it was British Telecom who held the trademark for the "Yellow Pages" name, and Sun was forced to change the name of their product. Did it cause confusion for the user? Maybe some initially, while people got acclimated to the new name in documentation, etc -- but the utilities, today, over 10 years later, still bear their original names of yp*. An earlier post mentioned other free projects creating symbolic links to the more widely known executable names, such as vim and elvis..
But even further, why must a project's name match the name of their executable? Apache installs httpd, not apached. (Ignoring windows, here). Samba installs [ns]mbd, not sambad. OpenSSH itself, as it is NOW doesn't install "opensshd".
All in all, I think the Open Source community needs to be a good neighbor here. This is more than a case of name usage, this is a case of a coder developing one of the most widely used pieces of software on the 'net. For better or worse, he chose to take it and make money with it, changing his license in the process. Should this negate the fact that the earlier code was out there? That he put the effort in to coming up with the protocol as well? I certainly don't think so.
Really, it doesn't take much effort to change the name of newly released products, and I don't think they're asking to change the millions of installed copies. All that would really be required is a new chosen name, and the registration of an appropriate domain.
Who knows, by being good neighbors, SSH Communications might even foot the bill for it.
If not, email me. I will.
-Jeff
Gah. I wouldn't want to replace a $3500 laptop. :)
:(
Mozilla didn't render the preview pane right.
-Jeff
Mostly because for the desktop systems, there's no hacking needed.
I have a dual G4 tower that I only run Linux on (I develop on it.) I found that the one button mouse made it pretty difficult to work with. XFree86 supports "faking" multibutton mice, using the control/shift/option keys - but what happens if you need a combination that is already occupied by the "workaround?"
So, I just went out and bought myself two logitech optical USB mice (one for my development pc). There was no additional configuration required, it was just seen as having more buttons than a normal apple mouse.
Now, for laptops - that's a different story. I'm not familar with the internals of a powerbook, but I'd imagine that the trackpad is hardwired. I've seen USB trackballs that "clip" onto the side of the laptop so no desktop surface is needed. For the most part, I'd think that hacking a multi button trackpad into a laptop would be more trouble than it's worth -- besides, given the modular nature of desktops, it's easier to replace a $200 motherboard or a $50 mouse if you mess it up -- but I would want to replace a $3500 laptop whose warranty I just certainly voided.
Just my two cents.
-Jeff
So, if you piss them off (like keep calling for tech support, as mentioned in one of the complaints), they can just shut off your service, and it doesn't get covered by the 99.9% agreement.
Cute.
-Jeff
I'm sure the uproar isn't just over the ability to remember another digit.
There's serious money involved in the switch, when companies have to reprint stationary, advertisements, business cards.. make sure their applications can handle longer phone numbers correctly.
Seriously, just think about how many times when you enter your phone number while ordering something, if you mistype it -- it tells you that it's formatted wrong. That's just a small example of code that needs to be changed.
Just food for thought..
-Jeff
CAD$50 is like 50 cents in the US. :)
Seriously, though, using the current exchange rate, CAD$50 is about USD$32.
-Jeff
You're points are valid, but unfortunatly don't apply here.
All the examples you've chosen are either processor architecture or device driver related. Most of the code that both of these classes use in the "core" of the OS are non-architecture dependant, and are coded for best general use.
Forking the kernel for "big iron" may be required because utilizing that many resources effectively requires different algorithms at the very core of the OS - scheduling, virtual memory, caching, etc.
The advantage to forking the kernel is the simpilicity in maintaining the code for either. However, the major disadvantage -- as seen with the BSD's -- is that features in either tree just end up getting implemented twice.
It's a tough question to answer, and both choices have major long term implications.
-Jeff
I've posted articles on the missing features of Linux for a while. Most of them seem to be beyond the search threshold that Slashdot offers.
Hopefully, when I get some free time, I'll get the chance to attempt an implementation of any one of these. In the meantime, however, other people may benefit from a bulletted list.
So, here goes: Some of the features below, when read, will obviously require special hardware to support them. However, the hardware is useless without proper operating system support. Remember that this post is addressing features that commercial UNIX has and Linux doesn't. The details for the average developer obtaining the appropriate hardware to develop for and test on is irrelevant to this discussion.
Most people know the benefits of a journalling filesystem, but for those who don't: When your system is writing something to disk, even though the program you're using eventually boils down to calling a write() system call to get it done, the OS actually has to perform many steps. All a disk is capable of guarenteeing is a single atomic write of a single block. Now, if you're writing out a file, this consists of many block writes for the data, but also writes for the meta-data. Meta data is the stuff associated with files, such as timestamps, permissions, links, but also stuff that the user never sees that maintains filesystem integrity. If your system crashes, loses power, etc during the middle of a meta-data write, you can lose an entire filesystem. At the very least, you'll end up with a potentially lengthy fsck(8) when you reboot. A journally filesystem essentially uses a "staging" area, where all writes to disk are queued up -- also on disk. A file and associated meta data can be guarenteed to be written or not written -- but not half way. If the operation did not complete, the operation can be completed when the system comes back up. This is called a replay, and it uses the journal to do this. Filesystem recoveries take seconds, instead of minutes or even hours on huge filesystems. Going into more detail is really beyond the scope of this post, but you get the idea.
I hope this clears up some of the clouds surrounding this sort of thing. I noticed that my original post was moderated down by someone ambitious as a "troll", when in fact it was not meant to be one at all. One of the major weaknesses of the Linux/BSD/Open Source community, and this has been mentioned before by people more known to the public eye than myself, is the inablility to look at the faults. No OS, including Linux, is perfect. The ability to see the imperfections, the flaws, the faults, and the missing features is what can enable the Open Source community to improve their software even more. Turning a blind eye to real issues does nothing other than stoke the fires of corporate ignorance as well as being self-fulfilling FUD.
Comments welcome.
-Jeff
Hopefully, when I get some free time, I'll get the chance to attempt an implementation of any one of these. In the meantime, however, other people may benefit from a bulletted list.
So, here goes:
While I realize that this may come as a shock, modern commercial UNIX platforms are no more a 30-year old system than Linux, FreeBSD, or anything of the ilk is.
The idea that UNIX hasn't evolved at all over the last thirty years isn't just wrong, it's a position dangerously close to ignorance for a computing professional to take.
Many of the features that Linux and the *BSD's still lack are features that have been standard in commercial UNIX for years. Even with the growing number of Linux servers out there hosting web sites, most major e-commerce sites out there aren't using it. In the enterprise computing arena, the competitors are mainframes, UNIX (solaris, digital unix, hp/ux, etc), and (unfortunately) Windows NT/2000. It's a battle that Linux simply isn't mature enough to take part in yet.
Now, this isn't to say that Linux won't get there -- far from it. Linux, with the freight train of momentum it's got these days, will probably have a comparable feature set in a few years. However, decisions aren't made on vapor -- they're made on what can be rolled in today.
Competition in the desktop arena is also an area where Linux is ill-suited to compete. Microsoft completely dominates this market, and for most users, Windows is it. At this point, Linux can't compare to the user friendliness that Windows provides. [*]
Now, I'm a UNIX geek -- I earn my living running enterprise UNIX servers. I've also been running Linux at home and on my workplace desktop since mid 1995. Professional decisions aren't made on personal preferences (unless the technology involved is comparable) -- they're based on usability and technical merits. Linux, at this point, is mostly suited for the technical users' desktop, or the low to low-midrange server market.
-Jeff
[*]: Technically - yes, stability is part of user friendliness, but for most desktop users it's not a primary concern.
.. yeah, and that the case itself could interlock onto the desk surface.
Having lego drinking glasses and other such things would do wonders for desk neatness.. nothing could tip over!
The guy who built this stuff is my new hero.
-Jeff
Most VPN software packages aren't running over TCP/IP. From what I've seen, everything from Cisco-Cisco router tunnelling all the way to MS VPN software uses IP Protocol 47. (GRE/IP) In the case of MS's they also use a TCP/IP port (17xx something) to provide authentication.
Disallowing most VPNs would be as simple as blocking IP protocol 47 at their gateway router. Trivial. "gre deny any any" in Cisco's IOS parlance.
As a reminder (and not really related to the post I'm replying to), VPN != Masquerading, although many sites could "detect" masqueraded traffic simply by watching for a higher-than-normal use of ports over 60,000. Most network providers - even companies and schools - have network monitoring hardware. I've learned how to configure Netscout probes and software to show me information very similar to this.
IPsec is also used, but I'm not as familiar with the details of that.
-Jeff
I'm an advanced user, so my opinion of what might be good for a beginner is probably very skewed.
I've been running SuSE for a while now, since a co-worker of mine went to work for them. One of the major things that attracted me to it was that one of the install options is the ability to choose ReiserFS as your default (root) filesystem.
I first installed 6.3. Recently, I installed a new box with 6.4-eval (they call their downloaded versions evals). I'm not at all afraid of non-graphical installs - I've been installing commercial UNIX boxes over a serial console for years. I found myself very much impressed with the graphical configuration/installation that SuSE has going. It found my hardware, presented appropriate technical options [module params] if you wanted them, etc.
All in all, I think it's a perfect blend of easy-to-use, and the level of control that your typical UNIX geek wants. The configure scripts are well thought out, and centered around a core "/etc/rc.config" settings file - which you can edit yourself if you wish, or have YaST do it for you.
..and it comes with damn near everything, but doesn't install all the fluff unless you want it to.
They offer add-on packages that aren't really part of the distro because they're not really mature yet, such as XFree86 4.0, on their FTP site.
Furthermore, they're going from a release 6.4 to a 7.0. This isn't abnormal. Part of it may be version creep - but it really wouldn't surprise me if it does, in fact, merit a full version increment.
I've tried most of the major Linux distributions - and SuSE is the one I've stuck with.
-Jeff
Actually, many modern systems don't require that the filename match. They load libraries by library name, which can be embedded in the actual library.
/etc/ld.so.conf. The location, so long as ld.so can find them, is irrelevant. What *is* relevant is the different compile options and versions that different distributions use in their install.
Try moving libsomething.so to liboldsomething.so, and then doing an ldconfig. It will find the liboldsomething.so as libsomething.so.
...and as a reponse to the question above about library locations, the linux ld.so finds all the libraries for you, as long as you've placed the directories in your
-Jeff
% man ld
/-soname
n
-soname name
When creating an ELF shared object, set the inter
nal DT_SONAME field to the specified name. When an
executable is linked with a shared object which has
a DT_SONAME field, then when the executable is run
the dynamic linker will attempt to load the shared
object specified by the DT_SONAME field rather than
the using the file name given to the linker.