What about Netscape? Is Netscape diffrent from Oracle or Adobe? They are all not open source... So... ? Is open source relevent to system administration (IMHO, NO, it's not). It's either part of the OS and goes in/usr/bin (which I HARDLY consider any of those examples part of an OS), or it's an add on (and doesn't matter if it came on a distribution CD or downloaded directly from the company that wrote it) so it should go OUTSIDE of/usr/bin and maybe into/usr/local or/opt.
But it's not that fragmented from an ISV standpoint compared to Linux. At least they know where to install thier software and libraries, and have a set standard on how to make applications run on a variety of the distributions of Windows.
Having lot's of Linux distributions focused at specific target markets is probably good, the more the better.
The problem is the incompatability and fragmentation between the distributions. I'm not talking about diffrent kernel or library versions, or even about diffrent package management. I'm talking about diffrent init levels, diffrent init scripts, diffrent paths for add on software, and totally diffrent layouts. (Maybe even diffrent packaging, but I like diffrent packages, I would only ask that they maybe consider standardizing the metadata, which is something they are quitely talking about already).
I agree with many of the artical points, but I say that he is dead wrong, and companies like Chilliware (or whatever it's called), Conectiva, and have plenty of room to create specific nitch application or language focused distributions.
The problems all stem from lack of standards (again), which make ALL distributions result in some "roll your own" needs when you start adding stuff you want (like Adobe, Oracle, or any ISV applications) and integrating diffrent systems into the same network. Time will tell, but (again, IMHO, and probably flamebait) it's just because the standards groups are more worried about finding a middle ground through the path of least resistance, rather than doing what they should and laying down a few laws based in logic and substance.
I think I downloaded it from Adobe, as an.rpm, and it went into/usr/local? I don't remember for sure. But, that's exactly the point. Even if the package manager or distributor are diffrent, there should be a defined place by the FHS for the software to go.
So, if I use a.deb, a.rpm, a.tgz, or a install script, it goes to the same place, as defined by the FHS.
That's exactly why I am against saying "Red Hat is an OS" and allowing them to put shit in/usr insted of/usr/local or/opt. They only make adding software easier if you never switch packaging systems, and always rely on them....
Hmm... Need to only use the one distribution or break links and paths... Oh... Now it makes sence (sarcasim), Why would they want to make things standard, it would only allow you to break free of being dependant on the Distribution!
"*/opt was designed for closed source Unices where there is a clear delineation between OS vendor and third parties."
Yea, sure, you can say that... But Adobe stuff is closed source and ends up in/usr/local... And, what about the old cry "Red Hat is NOT Linux, it's a distribution of software that includes the Linux Kernel."
Given that, shouldn't all of the packages that come on a CD Distribution of Linux go into/usr/local, because they are NOT the BASE OS, they are added on packages? (yes, argueable, but only with the "but/usr/local shouldn't be touched during an OS upgrade" statement)
What is an OS upgrade? Should an OS upgrade really include anything that a distribution wants to put on as many CD's they feel like shipping? Or should the OS be considered the kernel, and the fundemental parts of the system most commonly required (init stuff, a shell, etc....)
If I am going to make ANYONE work harder in this situation, my choice is the distributors, not the users. If distributers have to figure out what to put into/usr/local, what to put into/opt, and what to put down in/, then so be it. As long as it's logical, and makes it easier for the end users.
If the end result is that the users can truely see that/opt can be exported, and thus they only have to install those packages ONCE on ONE system on thier network, but the stuff in/usr/local is only configured for that system (like apache, etc...)... And the really basic shit that every system needs to run, and stay running for maintaince and stability is down in/, whooow baby... that would be awsome.
/opt and it's implementation is obsolete. But that doesn't need to be the case. It's something we can use constructively. KDE once went into/opt, based soley on the fact that part of it (qt) was "non-free." And I'm more than positive I can poke around on some NON-Linux *nix's (Solaris, IRIX, etc...) and find GNU stuff compiled and installed in/opt (thier conventional place for add on packages).
IMHO/opt is due for a make over, and now (when it's starting to be less used, and more confused) is the time to nail it down and make it useable.
But it's probably not worth arguing, because I am looking at it soley from a system administration, user, and logical standpoint. The people who control the standards are looking at it from a "mediator between big OS vendors" standpoint. They only seek to find a workable middle ground, not a truely logical way of doing things... So, it's all a discussion in vain.
Yea, the/opt/pkg_name/ thing has been frequently used. And, it's got merit.
But, the/usr/local/pkg_name/ thing is also frequently used in the past as well, (by Adobe, Apache, and others).
This does make a case for "each package in it's own directory vs. package management (metadata)." My vote would probably go down for package management, and leave it up to the system admin to choose his/her method of managing thier packages.
IMHO, symbolic links are always just a messy workaround, and the thought of a directory for each package that far down the path strikes me wrong.
I guess I personally think of things in an old fashion UNIX sence, where you have one system that exports a lot of stuff, and many workstations that just read-only mount the executables on that server.
The growth of PeeCees and "a workstation on every desktop" have changed that. Everyone wants thier own system, with all thier own binaries, all on thier own drive... and that's a system admin nightmear. Not to mention that you are tied down to YOUR workstation, and loose all of the oldschool UNIX style networking (xterminals, sit anywhere and use your account on any server, all boxes are roughly equal...)
Maybe it's not just the growth of power to a single computer that has caused it. No doubt big hard drives and lots of free cycles have done a lot to make people believe in the "MY COMPUTER, YOUR COMPUTER" mentality. But a lot of the credit probably goes to reaching bandwidth limitations (10 uses on 1 server from 10 xterminals can be taxing on bandwidth as much as on the server memory and cpu).
But old school UNIX still has merits that we are throwing away if we don't try to simplify the basic file hiarchy system. NFS mounting/opt/bin from a bunch of boxs running on FlashRAM or CDROM only would rock (not to mention save money on each workstation, leaving more money for a killer server).
Add encription to the mix for more fun. Xterminals need much less bandwith (a limiting factor) and just a little more CPU power (not so bad) to have a encripted X session. That not only gives a wee bit more security, but frees up some bandwidth.
Now... Let's take ALL of that cute idea from oldschool UNIX, and add some SlashDot style new school 3l33+ script kiddy ideas.... "Imagine a Beowulf Cluster of these!" Yea, it could be done. Have 1 computer lab, containing 20 workstations, all running as 1 distributed system. You log into one, and while 10 guys sit browsing the web using very few cycles, you have access to the CPU power of all 10 systems to compile your latest project... Hmm.... Ok, now I went over the edge... I'll shut up now.
Your focused entirely on GUI there in your comments, and that's not where the real problems are.
From an end user standpoint, GUI standards for *nix systems would be very nice, and make life easier.
But competition is good in GUI, and if you choose to stick with one tool kit (motif, gtk, qt, or whichever), then you can already find a great deal of consistancy. Trying to merge a mix of GUI tools, your always going to be asking for inconsistancy.
Actually, when you think about it, the mear fact that you can run all of these diffrent apps based on diffrent tool kits and phlosiphies is pretty cool.... Even with the inconsistancy of copying, button style, whatever.
The real issue that they need to deal with is the structure of the OS underneath. How to make all those diffrent apps compile, and install, and work, and seem to follow a logical structure from the underside.
Let's stay focused on the ground before we try to touch the stars. adding consistancy to the GUI is not something I think these specific standards comittes should be wasting time on. Let's make the apps run, the systems talk to each other, and the process of configuring stuff more logical first.
--INSERT SARCASIM-
Again, the self claimed gurus of standards frantically address the problems of fragmentation. But, as usual, it's a fierce fight to find a middle ground between various distributions (if you wish, including Linux as a now heavy and already fragemented player along with the other standby *nix systems).
While all the troops lay out in the trenches of the subdivisions of/etc/rc* and/var/godknowswhy the real working system administrators couldn't honestly care less, they know the intricate deviations of each *nix they use already.
Lost in the trenches, the architects of the new FHS fail to see the growing problem of network integration, and the lack of logical in the situations of day to day mantainance.
If they had some balls, they would see, the battle should be for the greater good, and as such, ALL of the FHS should make a major shift in philosophy to how to make *nix systems more friendly.
Most already agree that the bin, etc, var, sbin, home, lib structure works pretty well. So, now use it!
IMHO, what needs to be done is:
make/opt the place for EXPORTABLE. Subdivide/opt into the basic components,/opt/bin,/opt/sbin,/opt/home,/opt/lib,/opt/etc, etc... Then, all the exportable home dirs are in one place... all the binaries that can be run on similar architecture go in the exportable by design/opt dir. (exportable is not/mnt,/mnt is only for TEMPERARY stuff).
make/usr/local REALLY LOCAL. Define it's structure like / and/opt, with/usr/local/etc,/usr/local/var,/usr/local/bin, etc... Put all the system specific stuff that isn't really part of the base OS (like apache and it's configuration files) in this LOCAL directory. Users who only run on that ONE system have a/usr/local/home
make only the NEEDED stuff that is truly the BASE of the OS go into/, like the kernel, a shell or two (with the extra shells like zsh and such in/opt/bin), basic init stuff (and I don't care if it's SysV or BSD personally, as long as I know where to go to find it).
Just basically make some sense of it all! I know NO distribution (Solaris, Tru64, Linux, BSDs, none) will be compliant YET. But if they are making the standards, they need to have the balls to say "this makes sense, we need to do it, even if it takes a few years before everyone starts using it." In the long run, it is good for *nix. Everyone is just WAY to focused on short term middle grounds.... Why not focus on laying down a foundation that will not be continually growing more complex and illogical?
This is so typical of standards committees, put a band-aid on a harlequin quilt, and say it's all matching and compliant now. It's time to throw that quilt in the washer with a package of clothing dye, and REALLY make it all match.
Thus, finally, my annual *nix sux rant is complete, commence the flaming.
Hmm:
The Debians and Slackwares of the world will always be around to annoy monolithic, all consuming companies like RedHat. god forbid that some Linux distros actually become COMPATIBLE and CONSISTANT
I believe Slackware is still boycotting the LSB, with their initial statement that it's just a waste of time, and they would rather spend time on something real like POSIX or UNIX98.
I'm probably going to have to take the side that Patrick Volkerding was right 2 years ago when he said it's a waste of time. The LSB is just not making a dent. Yes, the goal is nobel, but the methods of the LSB seem confused and ineffective.
"What's up with listing "Linux" as the offending party?"
In related news, the GNU Software Foundation has filed suit against Yahoo on behalf of Linus for slander.;-)
Yahoo has falsly reported that "Linux" was involved in illegal stock manipulation, when it fact the story was actually about Credit Suisse, a company representing VA, a hardware company.
I don't want a single number. I don't think you do either if you think about it.
Manufactures would just figure out what was the cheapest way to get their number up, even if it meant graphics rendering went to hell because they spent all thier budjet on cache or something... It wouldn't be a fair comparison. You need lot's of numbers, AND, don't think the CPU is the only thing that will effect them!
Hmm, maybe someday I'll find some free time to finish hwinfo2html then at least I would feel a little better about comparing system... But... I have zero time, and it has a LONG way to go before being truely usefull.
Did anyone read the article at all? It says "On the American side a road would have to be built from Fairbanks in the face of objections from environmentalists." But the very next sentance says something about a "mainline station."
Is the tunel to be a combo road/rail tunnel, or train only, or what? Or is it just some UK version of English that a "road" is actually something that trains travel on?
Uh yea... K... Well, let's base the system on something natural.... The earth is round, how about we base the calender on PI. (and get an excuse to calculate it more....):-/
Base 10 is a convention based in culture and language, not on science. So yes, it's sorta stupid. But defining a natural base unit for time might be difficult unless you do it at an atomic level (atomic clock... Hmm, gee, there's an idea... Oh wait, they did that already).
Your base units for time (being subjective to our planet) are ~365 for days, and that can't be changed substantually without changing allignment to the seasons. No one would want that.
But, as for how to devide that 365 up, there are more ways than you can count (pun intended). How about the seasons, there are 4 for a reason (longest day of year, shortest day of year, etc...) Then you end up with 365/4 to give you the quarters... Then, who gives a heck? Maybe base a second like unit on an atomic clock... But how do you scale that up with out calling it a mega-atomic-modulation or some idiotic thing that would end up being based in 10 anyhow?
Bottom line is, most people who would spend any amount of TIME on the idea could come up with some interesting thoughts, but they will probably NEVER be accepted in my lifetime because our current system is to ingrained in our culture... so... Why bother...
Cablevision in New Jersey... heh... I remember the lack of service, and the letter. What it all came down to IMHO is some bean counter decided it would be cheaper to send everyone a letter than to credit them for the half day of no service.
Normally, the cable (TV) company credits you for the downtime if you ask. In this case, they are trying not to. Ah.. Bigger issue, ONE CABLE for all of thier clients in the whole state??!?
Am I the only one that looked at Whistler and had TWM flashbacks of flat colors, click anywhere on the desktop menus, etc...?
Why is it when Microsoft does ANYTHING it's eithet "revolutionary" or "evolving to something better." It' looks like a step backwards, space hog, ugly as sin interface to me.
Don't get me wrong, I'm not MS bashing (completely), I've finally broken down and installed Windows this year myself. They are getting a bit better. But, what they are doing is slowly changing the GUI to make it look new, while keeping it similar enough to not confuse everyone.
To speak about KDE and Gnome as an "environment" (not a toolkit) you have to realize, they are LIMITED by the ability of the USERS to understand the interface. OF F$#$@ COURSE they look and act like Windows, because "everyone knows how MS Windows Works." As inovative as they could be is still limited to what the average MS Windows user can figure out what to do.
Next Generation Desktops most likely are NOT going to come from Microsoft refining thier GUI. The newer cooler stuff seems to be with window managers like Enlightenment (gag... Ok, NEW? F$#@, I've used it on and off for how many years and it's STILL BETA?!?)
Screw you guys, I'm going home! (ala Cartman) TWM baby! Face it, even FVWM was only limited by the fact it did WAY MORE than most people could figure out how to configure.... and FVWM is HOW old???
Ok, granted you can go from existing ext2 to ext3, and not ext2->reisterFS. Given.
What I worry about is using reisterFS now for an install, and then something like ext3 becomimg the more "accepted" file system. Then, it won't be easy to go from ReisterFS to ext3 without backup/format/reinstall.
I agree, that would be better. But, you just set yourself up for a lot of work. Care to develop a RFC for your idea, submit it to... Hmm WHO? (there are groups I'm sure, I personaly don't know though). Then you need to rally support, and constantly approch the whole banking community to promote the idea (which, BTW, with bankers, even getting thier attention for a lunch meeting will cost a lot of money).
I just suggested we petition Quicken because it can probably be done much much much more quickly and easily. If your out for the best solution, your right, absolutely. I'll support you in idea, but I don't have the time or energy to help you do it. But I would be damn happy to see it;-)
I recently looked, and ended up quiting that quest and went after the best deal for online banking (I finally got a laptop with Windows, I've been UNIX only for about 5 years).
bankrate.com is good source of bank info, I went with netbank for my newest account but haven't tested it yet with Linux (Only got freebsd installed at the moment on my UNIX systems, my wife has Mandrake on her computer, I may test that later). I'm using Summit Bank (www.summitbank.com) for one account, that works fine in FreeBSD, it's all web based, and checks for browser security, not OS.
The real problem is Quicken. All the banks trying to develop online technology are trying to fully develop thier ability to work with Quicken. And Quicken is somewhat a moving target with new versions every year. For online banking, Quicken is important, people are asking for full support from thier bank for Quicken a lot more than for Linux (or any other UNIX) support.
So, if you really want online banking in Linux, what you need to do is petition Quicken to release a Linux version. Then, banks will support it, because they are supporting one product, not multiple OS's.
I don't think there is an open source project (like gnucash) that quite supports "quicken protocol," nor do I believe Quicken will be likely to release a spec of thier protocol for someone to develop a free application that works as well as theres.
I for one would buy Quicken for Linux, if it was out.
Sorry, as a chemist, who has seen several talks on LED technology as it applies to both inhanced fiber optic data transmission and display tech, I have to say, your wrong, it's not "plastic" that they are talking about.
First off, I'm going to have to qualify this with "I have no idea what the LA Times is talking about, because they really don't mention any science"
But the trick is SAMs (self assembled mono-layers). If you start with molecules that will direct light, transport electricity, and/or convert electricity (often in the case of single electrons) into light, that's a big step. There is a lot of synthetic work that goes into finding the right molecules. And then, the hard bit, is creating them in such a way that they will densely pack onto a surface, by themself.
The cool thing about SAMs is the S and the A. They assemble themselfs. You just put the right concentration of these molecules in solution, and then create the right conditions for them to drop out of solution and onto a surface. This is done with a small electric potential on the surface, adding another analyte to the solution, or simply evaporating some of the solution away...;-) And poof... a nicely coated surface with your magic molecules. Of course, it's a bit more complex and involved than that, but, that's sorta the basic idea.
These things will not only make cheaper, sharper, brighter displays, but they will improve communications as well. As it turns out, fiber optic communications is not limited by the speed of light, we're communicating no where near that fast in the real world. It's limited by the speed we can accurately create a "pulse" of light to funnel down a fiber. And these cool little SAMs can be turned "on and off" faster than the current switches and relays that we use in fiber optic communication today... So, they will speed up data transmission too someday in the future.
My two cents... It's been a few years since I looked into this, and I'm sure I might have SOME of the details muffed up.... But that's a lot closer to what's going on than "they are just making better plastic."
Slashdot Mirror
What about Netscape? Is Netscape diffrent from Oracle or Adobe? They are all not open source... So... ? Is open source relevent to system administration (IMHO, NO, it's not). It's either part of the OS and goes in /usr/bin (which I HARDLY consider any of those examples part of an OS), or it's an add on (and doesn't matter if it came on a distribution CD or downloaded directly from the company that wrote it) so it should go OUTSIDE of /usr/bin and maybe into /usr/local or /opt.
/usr/local because it didn't come on the distributions 5 CDs of software?
/opt because it is optional software, and commercial (which some feel belongs in /opt).
Wait, what if it comes on Distribuition XYZ's 3rd CD out of the 7 CD set?? Then we stick it in /usr/bin?
FHS is NOT 100% clear on this. Yes, there is a standard in place. But, the reason it's being ignored is because it's as clear as milk.
But it's not that fragmented from an ISV standpoint compared to Linux. At least they know where to install thier software and libraries, and have a set standard on how to make applications run on a variety of the distributions of Windows.
The problem is the incompatability and fragmentation between the distributions. I'm not talking about diffrent kernel or library versions, or even about diffrent package management. I'm talking about diffrent init levels, diffrent init scripts, diffrent paths for add on software, and totally diffrent layouts. (Maybe even diffrent packaging, but I like diffrent packages, I would only ask that they maybe consider standardizing the metadata, which is something they are quitely talking about already).
I agree with many of the artical points, but I say that he is dead wrong, and companies like Chilliware (or whatever it's called), Conectiva, and have plenty of room to create specific nitch application or language focused distributions.
The problems all stem from lack of standards (again), which make ALL distributions result in some "roll your own" needs when you start adding stuff you want (like Adobe, Oracle, or any ISV applications) and integrating diffrent systems into the same network. Time will tell, but (again, IMHO, and probably flamebait) it's just because the standards groups are more worried about finding a middle ground through the path of least resistance, rather than doing what they should and laying down a few laws based in logic and substance.
So, if I use a .deb, a .rpm, a .tgz, or a install script, it goes to the same place, as defined by the FHS.
That's exactly why I am against saying "Red Hat is an OS" and allowing them to put shit in /usr insted of /usr/local or /opt. They only make adding software easier if you never switch packaging systems, and always rely on them....
Hmm... Need to only use the one distribution or break links and paths... Oh... Now it makes sence (sarcasim), Why would they want to make things standard, it would only allow you to break free of being dependant on the Distribution!
Yea, sure, you can say that... But Adobe stuff is closed source and ends up in /usr/local... And, what about the old cry "Red Hat is NOT Linux, it's a distribution of software that includes the Linux Kernel."
Given that, shouldn't all of the packages that come on a CD Distribution of Linux go into /usr/local, because they are NOT the BASE OS, they are added on packages? (yes, argueable, but only with the "but /usr/local shouldn't be touched during an OS upgrade" statement)
What is an OS upgrade? Should an OS upgrade really include anything that a distribution wants to put on as many CD's they feel like shipping? Or should the OS be considered the kernel, and the fundemental parts of the system most commonly required (init stuff, a shell, etc....)
If I am going to make ANYONE work harder in this situation, my choice is the distributors, not the users. If distributers have to figure out what to put into /usr/local, what to put into /opt, and what to put down in /, then so be it. As long as it's logical, and makes it easier for the end users.
If the end result is that the users can truely see that /opt can be exported, and thus they only have to install those packages ONCE on ONE system on thier network, but the stuff in /usr/local is only configured for that system (like apache, etc...)... And the really basic shit that every system needs to run, and stay running for maintaince and stability is down in /, whooow baby... that would be awsome.
IMHO /opt is due for a make over, and now (when it's starting to be less used, and more confused) is the time to nail it down and make it useable.
But it's probably not worth arguing, because I am looking at it soley from a system administration, user, and logical standpoint. The people who control the standards are looking at it from a "mediator between big OS vendors" standpoint. They only seek to find a workable middle ground, not a truely logical way of doing things... So, it's all a discussion in vain.
But, the /usr/local/pkg_name/ thing is also frequently used in the past as well, (by Adobe, Apache, and others).
This does make a case for "each package in it's own directory vs. package management (metadata)." My vote would probably go down for package management, and leave it up to the system admin to choose his/her method of managing thier packages.
IMHO, symbolic links are always just a messy workaround, and the thought of a directory for each package that far down the path strikes me wrong.
I guess I personally think of things in an old fashion UNIX sence, where you have one system that exports a lot of stuff, and many workstations that just read-only mount the executables on that server.
The growth of PeeCees and "a workstation on every desktop" have changed that. Everyone wants thier own system, with all thier own binaries, all on thier own drive... and that's a system admin nightmear. Not to mention that you are tied down to YOUR workstation, and loose all of the oldschool UNIX style networking (xterminals, sit anywhere and use your account on any server, all boxes are roughly equal...)
Maybe it's not just the growth of power to a single computer that has caused it. No doubt big hard drives and lots of free cycles have done a lot to make people believe in the "MY COMPUTER, YOUR COMPUTER" mentality. But a lot of the credit probably goes to reaching bandwidth limitations (10 uses on 1 server from 10 xterminals can be taxing on bandwidth as much as on the server memory and cpu).
But old school UNIX still has merits that we are throwing away if we don't try to simplify the basic file hiarchy system. NFS mounting /opt/bin from a bunch of boxs running on FlashRAM or CDROM only would rock (not to mention save money on each workstation, leaving more money for a killer server).
Add encription to the mix for more fun. Xterminals need much less bandwith (a limiting factor) and just a little more CPU power (not so bad) to have a encripted X session. That not only gives a wee bit more security, but frees up some bandwidth.
Now... Let's take ALL of that cute idea from oldschool UNIX, and add some SlashDot style new school 3l33+ script kiddy ideas.... "Imagine a Beowulf Cluster of these!" Yea, it could be done. Have 1 computer lab, containing 20 workstations, all running as 1 distributed system. You log into one, and while 10 guys sit browsing the web using very few cycles, you have access to the CPU power of all 10 systems to compile your latest project... Hmm.... Ok, now I went over the edge... I'll shut up now.
Like ABit's Gentus? Red Hat with patches?... Na, best if they just work on actually submitting the patches for thier hardware IMHO.
/opt is completely undefined, and if I want to make my installer go in /opt/thing/executable/app I'm pretty much free to do it.
Note my earlier comments about what they SHOULD be, but.... As for now, they are just about whatever you want them to be.
From an end user standpoint, GUI standards for *nix systems would be very nice, and make life easier.
But competition is good in GUI, and if you choose to stick with one tool kit (motif, gtk, qt, or whichever), then you can already find a great deal of consistancy. Trying to merge a mix of GUI tools, your always going to be asking for inconsistancy.
Actually, when you think about it, the mear fact that you can run all of these diffrent apps based on diffrent tool kits and phlosiphies is pretty cool.... Even with the inconsistancy of copying, button style, whatever.
The real issue that they need to deal with is the structure of the OS underneath. How to make all those diffrent apps compile, and install, and work, and seem to follow a logical structure from the underside.
Let's stay focused on the ground before we try to touch the stars. adding consistancy to the GUI is not something I think these specific standards comittes should be wasting time on. Let's make the apps run, the systems talk to each other, and the process of configuring stuff more logical first.
While all the troops lay out in the trenches of the subdivisions of /etc/rc* and /var/godknowswhy the real working system administrators couldn't honestly care less, they know the intricate deviations of each *nix they use already.
Lost in the trenches, the architects of the new FHS fail to see the growing problem of network integration, and the lack of logical in the situations of day to day mantainance.
If they had some balls, they would see, the battle should be for the greater good, and as such, ALL of the FHS should make a major shift in philosophy to how to make *nix systems more friendly.
Most already agree that the bin, etc, var, sbin, home, lib structure works pretty well. So, now use it!
IMHO, what needs to be done is:
Just basically make some sense of it all! I know NO distribution (Solaris, Tru64, Linux, BSDs, none) will be compliant YET. But if they are making the standards, they need to have the balls to say "this makes sense, we need to do it, even if it takes a few years before everyone starts using it." In the long run, it is good for *nix. Everyone is just WAY to focused on short term middle grounds.... Why not focus on laying down a foundation that will not be continually growing more complex and illogical?
This is so typical of standards committees, put a band-aid on a harlequin quilt, and say it's all matching and compliant now. It's time to throw that quilt in the washer with a package of clothing dye, and REALLY make it all match.
Thus, finally, my annual *nix sux rant is complete, commence the flaming.
The Debians and Slackwares of the world will always be around to annoy monolithic, all consuming companies like RedHat.
god forbid that some Linux distros actually become COMPATIBLE and CONSISTANT
I believe Slackware is still boycotting the LSB, with their initial statement that it's just a waste of time, and they would rather spend time on something real like POSIX or UNIX98.
I'm probably going to have to take the side that Patrick Volkerding was right 2 years ago when he said it's a waste of time. The LSB is just not making a dent. Yes, the goal is nobel, but the methods of the LSB seem confused and ineffective.
In related news, the GNU Software Foundation has filed suit against Yahoo on behalf of Linus for slander. ;-)
Yahoo has falsly reported that "Linux" was involved in illegal stock manipulation, when it fact the story was actually about Credit Suisse, a company representing VA, a hardware company.
Manufactures would just figure out what was the cheapest way to get their number up, even if it meant graphics rendering went to hell because they spent all thier budjet on cache or something... It wouldn't be a fair comparison. You need lot's of numbers, AND, don't think the CPU is the only thing that will effect them!
Hmm, maybe someday I'll find some free time to finish hwinfo2html then at least I would feel a little better about comparing system... But... I have zero time, and it has a LONG way to go before being truely usefull.
Is the tunel to be a combo road/rail tunnel, or train only, or what? Or is it just some UK version of English that a "road" is actually something that trains travel on?
Can anyone clairify?
Base 10 is a convention based in culture and language, not on science. So yes, it's sorta stupid. But defining a natural base unit for time might be difficult unless you do it at an atomic level (atomic clock... Hmm, gee, there's an idea... Oh wait, they did that already).
Your base units for time (being subjective to our planet) are ~365 for days, and that can't be changed substantually without changing allignment to the seasons. No one would want that.
But, as for how to devide that 365 up, there are more ways than you can count (pun intended). How about the seasons, there are 4 for a reason (longest day of year, shortest day of year, etc...) Then you end up with 365/4 to give you the quarters... Then, who gives a heck? Maybe base a second like unit on an atomic clock... But how do you scale that up with out calling it a mega-atomic-modulation or some idiotic thing that would end up being based in 10 anyhow?
Bottom line is, most people who would spend any amount of TIME on the idea could come up with some interesting thoughts, but they will probably NEVER be accepted in my lifetime because our current system is to ingrained in our culture... so... Why bother...
Normally, the cable (TV) company credits you for the downtime if you ask. In this case, they are trying not to. Ah.. Bigger issue, ONE CABLE for all of thier clients in the whole state??!?
Whow, what planet are you on? I have an Athlon 750MHz, 256M Ram, nice 32M vid card... I'll trade you for 4 500MHz G4 Boxes, what's your address ;-)
Why is it when Microsoft does ANYTHING it's eithet "revolutionary" or "evolving to something better." It' looks like a step backwards, space hog, ugly as sin interface to me.
Don't get me wrong, I'm not MS bashing (completely), I've finally broken down and installed Windows this year myself. They are getting a bit better. But, what they are doing is slowly changing the GUI to make it look new, while keeping it similar enough to not confuse everyone.
To speak about KDE and Gnome as an "environment" (not a toolkit) you have to realize, they are LIMITED by the ability of the USERS to understand the interface. OF F$#$@ COURSE they look and act like Windows, because "everyone knows how MS Windows Works." As inovative as they could be is still limited to what the average MS Windows user can figure out what to do.
Next Generation Desktops most likely are NOT going to come from Microsoft refining thier GUI. The newer cooler stuff seems to be with window managers like Enlightenment (gag... Ok, NEW? F$#@, I've used it on and off for how many years and it's STILL BETA?!?)
Screw you guys, I'm going home! (ala Cartman) TWM baby! Face it, even FVWM was only limited by the fact it did WAY MORE than most people could figure out how to configure.... and FVWM is HOW old???
What I worry about is using reisterFS now for an install, and then something like ext3 becomimg the more "accepted" file system. Then, it won't be easy to go from ReisterFS to ext3 without backup/format/reinstall.
That is cool, I'm supprised your post wasn't moderated up a bit more!
I just suggested we petition Quicken because it can probably be done much much much more quickly and easily. If your out for the best solution, your right, absolutely. I'll support you in idea, but I don't have the time or energy to help you do it. But I would be damn happy to see it ;-)
bankrate.com is good source of bank info, I went with netbank for my newest account but haven't tested it yet with Linux (Only got freebsd installed at the moment on my UNIX systems, my wife has Mandrake on her computer, I may test that later). I'm using Summit Bank (www.summitbank.com) for one account, that works fine in FreeBSD, it's all web based, and checks for browser security, not OS.
The real problem is Quicken. All the banks trying to develop online technology are trying to fully develop thier ability to work with Quicken. And Quicken is somewhat a moving target with new versions every year. For online banking, Quicken is important, people are asking for full support from thier bank for Quicken a lot more than for Linux (or any other UNIX) support.
So, if you really want online banking in Linux, what you need to do is petition Quicken to release a Linux version. Then, banks will support it, because they are supporting one product, not multiple OS's.
I don't think there is an open source project (like gnucash) that quite supports "quicken protocol," nor do I believe Quicken will be likely to release a spec of thier protocol for someone to develop a free application that works as well as theres.
I for one would buy Quicken for Linux, if it was out.
Let me be the first to flame my spelling ;-) my fingers have a mind of their own...
First off, I'm going to have to qualify this with "I have no idea what the LA Times is talking about, because they really don't mention any science"
But the trick is SAMs (self assembled mono-layers). If you start with molecules that will direct light, transport electricity, and/or convert electricity (often in the case of single electrons) into light, that's a big step. There is a lot of synthetic work that goes into finding the right molecules. And then, the hard bit, is creating them in such a way that they will densely pack onto a surface, by themself.
The cool thing about SAMs is the S and the A. They assemble themselfs. You just put the right concentration of these molecules in solution, and then create the right conditions for them to drop out of solution and onto a surface. This is done with a small electric potential on the surface, adding another analyte to the solution, or simply evaporating some of the solution away... ;-) And poof... a nicely coated surface with your magic molecules. Of course, it's a bit more complex and involved than that, but, that's sorta the basic idea.
These things will not only make cheaper, sharper, brighter displays, but they will improve communications as well. As it turns out, fiber optic communications is not limited by the speed of light, we're communicating no where near that fast in the real world. It's limited by the speed we can accurately create a "pulse" of light to funnel down a fiber. And these cool little SAMs can be turned "on and off" faster than the current switches and relays that we use in fiber optic communication today... So, they will speed up data transmission too someday in the future.
My two cents... It's been a few years since I looked into this, and I'm sure I might have SOME of the details muffed up.... But that's a lot closer to what's going on than "they are just making better plastic."