obviously. But this doesn't change the fact that packages break every day because of this inconsistancy. Many packages aren't built for flexability, but for it to just work by default. Once you start changing where you install the package to, you run into untested territory. This is why on windows98,Me,2000,XP, you can download a package, install it, and the package doesn't have to know what distribution its going into. It just installs it (either default location, or where you tell it) and looks in the standard location for any libraries it needs, and thats it.
This doesn't work on different flavors of Linux, or *nix specifically because of this fs inconsistancy problem.
I know, technically speaking, your filesystem shouldn't have to be the same across platforms. But application writers don't design their apps to be that way most of the time. Neither do packagers. For the longest time KDE would install into/opt. Redhat didn't like that, so they installed it in/usr/something. I can't even begin to describe the problems that caused within the KDE community. Sure, maybe it was KDE's fault. Maybe it was redhat's. Either way, it was broken, and it took a long time before solutions were readily available to fix this in KDE.
The same can be said about any large scale application for Linux. This is one problem what the LSB tried to address, but still has not been successful at.
On top of all this breakage that happens regularly, there is still the user interface inconsistancy that exists with the current classical system. There is no reason that the current system shouldn't be at minimum adapted to be consistant and intuitive, even if you don't change all the names of the directories. (name changing is just for niceness, not practicality. In solving the practical problems, they added niceness to the filesystem)
Note: none of this means I agree completely with Gobo's fs. They have obvious mistakes that should be addressed. But these are things that could be fixed in time (for example, putting root's home directory in/Users/gobo). The idea isn't flawed, just the current implementation (and only one or 2 problems with it off the top of my head).
Nobody is saying linux should have EXACTLY what gobo has. They are saying that it needs something similar, adjusted for practicality. Maybe if you want to seperate system programs from user programs, then have/System/Programs/ and/Programs/. Whats so hard about that? Nobody is saying that what gobo has is anything close to a complete solution. Just because you can see 1 or 2 problems with what they have doesn't mean that the entire idea of doing it is flawed. That is just shortsightedness.
The whole point is to make a distribution that can be maintained by a normal user. Nothing fancy. Desktop users are their own system admins. They can't memorize a filesystem structure that makes no a priori sence when all they want to do is open a downloaded file with a program somewhere on their hard drive. I can tell you one thing is for sure: MacOS & Windows XP, their directory tree makes a priori sence. These are the 2 most popoular desktop OS's. They are also the best 2 for most people. Currently, *nix isn't the best, and one of its shortfalls on the desktop is hellish administration with a filesystem layout that doesn't make a priori sence. And that is the point of this distribution.
These people have been doing this for a while. You haven't spend more than 10 seconds on it. What makes you think they have not done this? And where is your evidence that what you would want to do is broken inheritantly and by design, or just because of a bug or oversight?
Simple answer: you are ranting about something you know nothing about.
"If it aint broke (or at least if it aint real broke) don't fix it."
That is the problem. it is broke. You can't download an application and install it on linux. You can install an application package specifically designed for your version of your distribution. Then, many times there will be a bug in the packaging of the application because the application writer didn't intend for the application to go into a place that the packager wants it to go. So then you gotta download an updated package. This happens every single day, 365 days a year, on production systems across the world. It is called dependancy hell. It's also called non-cross platform package management. None of the distributions properly handle multiple versions of packages installed simultaneously (except maybe gentoo) and that is something that could easilly be solved on the fileysstem level, but has never been standardised.
I can sit here forever listing off stuff just like this that all roots back to the fact that most linux systems don't have consistant filesystems. Until this inconsistancy is fixed, dependancy hell will prevail. And so will filesystem bugs in packages.
And since it needs fixing, we might as well go ahead and revamp it to make it intuitive while we are at it. If you haven't noticed, this is exactly what Gobo is trying to do (though I agree that they are messing some stuff up in the process, but those are kinks waiting to be ironed out [noteably,/root ->/Users/gobo])
"One-size-fits-all is a Windows mentality, it's not, nor will it ever be, a Unix/Linux one."
You just contradicted your whole argument in your closing. One-size-fits-all is not only bad in the windows world, but it is also bad in the linux world (X, File hierachary, etc...).
The reason people bitch and complain about X is because it doesn't do what some people want. And there isn't any alternative to do what people want because there just isn't (It is out of the scope of this argument to determine why there is no competitors to X).
The same is true for the filesystem. People bitch and complain that its hard to understand, etc etc.. In fact, the linux filesystem is the single reason that package management is such a fucking BITCH across distributions. It also happens to be the root cause of great confusion to new users and application writers and application packagers. it is also the number one cause of breakage related to the packaging of applications. You have to realize that almost NOBODY (including programers, packagers, and home users) is a unix system administrator that has had 30 years to memorize obscure filesystem names, locations, and purposes for each. Having to look shit like that up (stuff you shouldn't have to look up) is tedious work. What makes it even more tedious is that every flavor of unix has a somewhat different meaning for their filesystem directories. So you are in the camp that proposes that system administrators should do more tedious work and less logical work?
Saying that you don't want Linux to be like windows doesn't change or fix these problems.
"this whole FS reshaping is a rediculous idea and goes against everything the LSB [linuxbase.org] has been tryig to fix, since there are so many deviants of GNU/Linux"
You are correct. It goes against everything the LSB has pushed for. That is because the LSB does not push for a standardised filesystem. They push for many different filesystems that the distribution decides upon, and then try to make them all compatible with eachother. LSB is the wrong approach. This has been proven in the years that the LSB has been implemented, and has existed. So far there has been not a single instance of cross platform package distribution in any shape, form or fashion, simply because the LSB allows too loose of a filesystem that any compatible distributer can change on a whim.
Maybe if LSB decided on a standard filesystem structure, this wouldn't be a problem, and people wouldn't be trying to reinvent the wheel.
Until LSB acknowledges that there is a filesystem/package management level need for multiple versions of packages to be installed simultaneously in standard locations, LSB will be irrelevant to anyone that wants to distribute packages in any form.
I don't agree that this particular distribution is solving the right problems. But they certaintly are asking the right questions. And that is what is important. They are pushing for a single standard filesystem structure, with standard locations to install files, without spreading your package across multiple disk volumes/directories.
Until this consistancy GoboLinux is pushing for happens everywhere, dependancy hell will exist on every platform that implements dependancies. It is as simple as that.
I think the root of the problem is that the LSB decided (well, got pushed into) allowing different filesystem structures between distributions. This was a mistake, and their reasoning is illogical.
When every "standardised" distrubtion has the same exact rules for filesystem hierarchy, then and only then will package management be cross platform.
As it stands now, LSB has done absolutely nothing to improve consistancy between distribtuions, and only allowed them to diverge even moreso, and saying that divergance is OK for compatibility. This is a wrong assumption, and should be looked at by the LSB group.
I like the idea of improving the linux filesystem structure, but I don't believe this particular distribution has anything new to contribute. They made some bad decisions, such as user 0 in/home, etc..
The only way to legitimateize any filesystem used on linux is for everyone else who wants to be compatible to use it just like everyone else./opt,/usr, and/usr/local is the cause of 99% of most problems when it comes to cross platform packaging. Not only this, but with consistant and standard locations to install files that allows many versions of a package to be installed simultaneously, we can finally get rid of dependancy hell. (note: AFAIK gentoo currently takes care of multiple package versions at the package/filesystem level, nobody else will even bother nor recognize that it is even a problem.)
just my 2 cents (no, im not a gentoo fan, I don't even use it)
I agree with what your saying. My point is that safe-ish and not safe are effectively the same exact thing. Just because its easier to exploit non-safe systems doesn't mean that its impossible, or even difficult to exploit the safe-ish one.
In the end, I believe OS X is no more secure than running as root (except that joe user can't screw up his own machine, which isn't the real issue people are complaining about here). As it takes the Administrator user to activate the root account, and the administrator user is the default user, a virus could just as easilly get root locally if it is already installed on the administrator's account (which, may I remind you, is the default user).
I agree that a safe-ish approach is good to give people the sence of security. At least it protects the system from its users unintentional fuck up's. But that is about all it does. (And I do agree that something like this is needed to stop support nightmares, and improve stability) But I do not believe that there is anything inheritantly more secure using the safe-ish MacOS X approach.
In my eyes, a good comparison is that in order to imporve Homeland security, lets restrict our local citizens use of this land, rather than the remote terrorists. After all, that is the American Way!
What are you talking about? If it ain't root, its something like it.
we just got 3 new apples in last week. I set all 3 of them up. Every single one of them runs as root by default. What in the HELL are you talking about?
(note, non-root users shouldn't be able to access system level control pannels)
The default user has access to the entire networking configuration, hardware pannels, everything. That at bare minimum is write access to/etc by the default user, which is far from non-root.
I haven't pulled down the consol, but I'm willing to bet that I could write to any directory on the fs. And if I can't, it still doesn't change the fact that there is write access to/etc by the default user.(I can't check now because I don't use macs at home) Sure, it might not be the one true "root" account, but that doesn't change the fact that it has super user powers.
I use it every day for remote desktops. XFree86. I also use it locally on Linux. Every day.
I just happen to know (unlike you) that its not optimal for local display. There are better solutions out there that are faster, more efficient, and more suited for local desktop use. Sure, XFree86 does the job. But far from optimal. The competition has proven this. XFree86 was designed to display remotely. That is what the entire X protocol is used for. It just so happens that you can use the same principles to display locally
Until you realize that XFree86 is slower than most 2d desktop rendering systems when used locally, you will be blind of the facts. Its as simple as that.
Your an idiot by the simple fact that you think DHCP is a bad thing for either the provider, or users.
No matter what OS you are using, if you use DHCP, it is about 500000 times easier to setup for your users, and for the provider, and for the tech support, and for the troubleshooting. What do you suggest to use besides DHCP? PPPoE? LOL, Static IP? of course not.
Assigning static IP's to each user would be a nightmare to support. Using PPPoE just adds 30 extra steps to the setup process of each machine
I have seen a few implementations of IP Nexus and packages like it. It seems to work well. We use it campus wide here to keep public access ports secure. It works great. (DHCP every MAC that wants to connect, but don't route their traffic, then authenticate via https)
"Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?"
No.
You are missing the point. The point is to directly render all local desktops. Why on earth would you indirectly render your local desktop just because you are too lazy to implement a direct rendered model? That is the objective of DirectFB:
To implement the X protocol OVER a direct rendered local model, rather than implementing local models over X's indirect model. (note, this is how X clients work in win32))
The problem with all you X zealots that think you are god and all knowing is that you actually don't know everything. And you have proven this in your post.
"X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER"
Actually, your wrong. If you knew anything at all about how X works, you would realize this.
The reason that X is slow locally is because 2D windowing isn't directly rendered like DRI 3D or DirectFB. In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.
So insted of making XFree86 use direct rendering for local use, people are making side projects that don't implement the X protocol. Why would they? They would have to be compatible with 30 years of legacy API, which would hold the project back technically considering there are limited developers.
The problem everyone has with X is that the people who control X do not care about local performance for 2D windowing. They consider that since local methods are just special cases of the remote methods, they will be at least the same speed, or faster than remote, and that's good enough for them. The answer to everything is to put an X layer over a direct rendered model. But this is either out of the scope of the XFree86 Project, or is something they do not want to deal with (since none of them really care much about local performance).
In these shameful times, Americans cannot drink in the pub until they are 21 YEARS old. Isn't that insane?
Re:I agree, HDD, not optical, not solid state...ye
on
Solid-State DV Camcorder
·
· Score: 3, Insightful
The main reason technically speaking to keep tape is because it can withstand far far far greater G's than a hard drive. You can smash your camcorder on the sidewalk, and as long as the circuitry and gears didn't break, you can keep taping. With a hard drive, the fucker crashes on first glimpse of fall.
A camcorder with a hard drive in it is going to be more delecate, no matter how you look at it. Even if you used external FW hard drive in a backpack, you still can't be jumping up and down while using the camera.
Tape is the best media that is going to be available for camcorders in the near future. Until solid state flash chips become like CD-R in price, they aren't going to take off. Optical drives are going to kill battery life with the powerfull lazer, and the high speed motor.
What they really need to do is come up with some kind of smaller form factor tape spindles with higher density data storage. So you could fit the motors, reader/writer, and tape and everything in the size of a current 8mm cartrige.
The idea is this: which is cheaper, tape recorders/readers, optical recorders/readers, or magnetic disk recorders/readers? Tape is the answer. And its more durable under high Gs
I think the main drawback is its heat sensitivity being less than that of optical or hard drives or flash. But that is only a problem in certain climates.
I would suggest to not dismiss tape because its the 'old' kind of storage we used in the 80s and 90s. Tape is just a physical medium. We have been using disks even LONGER than tape (records)! New tape is good. It's digital. It's data redundant. It's low powered. It's high density. It's CHEAP. Don't let the misconceptions of tape being inferior because they are "old" technology slant your choice.
If the drive is being accessed, a 1 foot drop could crash the head all over the platter. Once that happens, there's nothing you can do about it. Even on the most expensive drives, this will happen.
The solution is to spin the drives slower, and so you can have the head placed farther from the disk. This increases the force it takes to get the head to crash. They do this in laptop hard drives, but still it's not gonna withstand anywhere NEAR 10ft.
Even if you don't notice damage, it is possible for a head to damage the platter and you can get bad sectors. Nowadays, hard drives automatically hide their bad sectors by using data redundancy on the disk. So you might not notice it, but if important data is being stored in that area of the disk, its redundancy is greatly reduced, and your data is not as secure.
Of course, technically the manufacturer is supposed to detect bad sectors and mark them as such(internally in the HDD, the OS has no knowledge of this), but not many MFG's do that in the real practice in the IDE world because they hide it with data redundancy.
Most states do not require your business to be in a business zoned space to get a business license. In fact, most zoning regulations allow home offices and home businesses in residential zoned locations. The zone regulations are ONLY FOR TRAFFIC. If you are a retail front, you need to be zoned that way. If you are a single software business owner who R&D's in his basement and sells on the internet and you don't get shipments all the time like a real business would, you don't worry about zoning. Home offices and Home businesses are legal, legitimate, and perfectly fine in residential zoned areas.
"emulate: 3. Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system. "
I hope you know, that by definition, an emulator is an implementation of an interface. In this case, and Application Programing Interface (API). There is nothing special about WINE that makes it not an emulator. Sure, it may or may not have more or less features than the reference implementation. But that is beside the point. It is one, by the very definition of emulation. WINE Is Not an Emulator is just another GNUism. just like LAME Ain't an Mp3 Encoder(which it is).
Just thought you might wanna know that before making such silly claims as above.
I too agree that the BSDL is better for government funding. This means that anybody can use it for anything, no matter what. You can't do that with the GPL. The BSDL is closer to the public domain than the GPL, and that is why it IMO is considered better for that type of stuff.
I think that although the GPL is less likely to be exploited by big monopolies, it goes against the principle of government funding. In the end, my ultimate view is that we should modify the government's BSD like license to state that it is illegal for a monopoly to use BSDL code in any product. I haven't thought it through very lengthly, so I havent though of any holes in this idea. But I believe that monopolies don't have rights, they have restrictions (morally). And if you are a monopoly, you should not have the right to what the public spent their hard earned money on.
I see your point, but my example of cars and drugs are closer than you realize...
I will attempt to compare the costs of each of 4 industries I mentioned (software, music/movies,drugs, cars*).
1) Negligable reproduction cost * 2) Negligable raw materials cost * 3) Very high R&D costs 4) Slightly high QA costs (including FDA approvals) 4) Advertising cost 5) Negligable market value/inflation/deflation cost of manufacturered yet unsold product cost
* does not apply to cars
(note, these apply to just about everything in the computer industry, except printers which is more like cars than computers. Even CPU's and memory can be considered an "IP" driven market)
Basically, any IP driven market is comparable to the above. The difference that software has when compared to the other industries is that there are significantly more people capable of producing quality software than there are bioligists/chemists and musicians to produce drugs and music/movies. For this reason, software has much more competition then the other two main IP driven markets presented above.
The reason my first comparison was about cars is because, if you change classifications and consider labor, raw materials, and equipment costs as "fixed costs of the product", then the IP driven markets and raw materials driven markets merge into the same thing.
I compensated for this by including the factory and raw materials cost into the "government grant" in the hypothetical situation. But I will agree that since replication costs are the most significant part of a car, and the least significant part of IP driven markets, my example is somewhat invalid.
However, Drugs, Music, Movies, and Software are still (in my book) all IP driven markets that have negligable replication costs. The drug companies and entertainment industries have already proven what kind of monopoly can be had on IP driven markets by lobbying congress with billions of dollars a year to keep marijuana and other effective alternatives to manufactured drugs outlawed, government R&D grants expanded, outlawing devices that are capable of replicating raw data that has been negligably encrypted, and letting false advertising and trademark violations (illegal use of the Compact Disk trademark to manufacture non-compliant CDs) and anti-competitive behaviour reign in these industries. I think the reason software isn't already in that state is because its market(for the mass public) is significantly newer than drugs and entertainment, and not all of the monopolies have firmly pushed out everyone and lobbied congress for laws which do the same for them (but you have to admit that some companies such as MS have already started doing this).
I think that a BSD type license has the potential of supplementing a RIAA/MPAA/DrugCompany-like monopoly in the software industry moreso than a GPL. However, I am still standing by the fact that I believe the BSD license has better usefullnesses in certain circumstances, and the GPL others. I am not a GPL proponent, nor a BSD proponent. I also fail to see where I am confused on the issues. I am mearly pointing out other viewpoints that you have failed to mention that tell the opposite side of the story you have told.
I do not believe that the BSD Core group could ever "close" the BSD source. I am mearly saying that it is technically possible for a hostile government sanctioned (through lobbying) illegal monopoly (similar to the RIAA,MPAA, and Drug companies) to effectively stop the use of BSDL software if they so desired by not allowing competition (even 'free' products) into the marketplace.
Microsoft has shown how this is possible by monopolizing the Office Suite and Desktop OS markets with proprietary and closed file formats and protocols. I just don't think Microsoft is completely there (at least not yet, if ever).
My main point is that BSD is easier to exploit through illegal (but government approved) practices (for example: microsoft).
Obviously, you must be doing wrong to do as I have described. My main point was that it would be impossible for someone to exploit is as above using GPL, but much easier to do with something like BSD.
I don't want to say that we should shy away from BSDL, but I was just giving an alternative viewpoint that I think is equally as valid and sound as the Pro BSDL argument.
All it takes is a hostile monopoly, and no "startup" can get into the market, no matter how little value the monopoly adds.
I think drug companies are a prime example. And very real at that. It is IP they have, not manufacturing processes, materials cost, etc.. They don't even pay for most of the R&D, it is all government grants. In fact, they spend less per year on R&D and manufacturing than they do on advertising and lawyers.(very similar to the RIAA and MPAA) The only difference between my hypothetical software example and the drug companies is that patent law is what determines who can use the IP, and not copyright law.
Of course, when the government gave them grants, they didn't have any restrictions on who owns the IP (they kept it, not the public). In the OpenBSD case, they were granting that the public gets access to the IP that was created with the money. So there are slight differences that are hard to weigh when looking at this case.
Note: I'm not a GPL proponent, but I'm also not a BSD proponent. I'm just trying to give you yet another POV that you may not have thought of.
Ok, so let me give you this little scenerio for a second..
So Ford and GM are making all these cars. Some open source car design starts up. All these mechanical engineers are designing this car engine and body in their spare time on the internet. Eventually, the design team (on the internet) decides they need more money to be able to build a factory to manufactur this basic car that they say will be cheaper for consumers.
So they get a government grant. They build the factory, hire factory workers, hire full time engineers to make more improvements on the design. Soon, you have a working car with a decent design, for pretty good price. The public just foot the bill, but its a Good Thing for the public because now they have this car for cheap! Right?
Wrong.
Since these cars are "BSD" they are cheap to everyone. Including Ford and GM. They are cheap because the government foot the bill for the factory and the engineering designs. Now Ford and GM get all these cheap cars, spend a slight amount of money, and improve it, can it to consumers, and profit to fuck, all while the tax payers foot the bill for their R&D, factory costs, and labor.
On the other hand, if these cars were more restricted... Somehow make a rule that doesn't allow a company to rebag the governments car with a few bells and whistles for a profit, while maintaining a monopoly on all cars (a monopoly which may or may not be granted by the government, ie: MS). If a rule somewhat like this were made, then taxpayers wouldn't be footing the R&D and manufacture bill for big coporations that own monopolies on said product.
But then again, a grose, shameful, and very real example of all this in today's world is the medical drug industry. We already have this, but insted of copyrights, its patents. Where the government spends more R&D dollars on drugs than drug companies (which spend more on advertising than R&D)
The end result is the same in all circumstances. The rich people who are making money off these coporations profit more, while everyone else pays for the R&D that is making him wealthier than the rest. So while BSD might be a good thing in general, I do think it is more suceptable to being exploited by big monopolies such as microsoft.
Slashdot Mirror
obviously. But this doesn't change the fact that packages break every day because of this inconsistancy. Many packages aren't built for flexability, but for it to just work by default. Once you start changing where you install the package to, you run into untested territory. This is why on windows98,Me,2000,XP, you can download a package, install it, and the package doesn't have to know what distribution its going into. It just installs it (either default location, or where you tell it) and looks in the standard location for any libraries it needs, and thats it.
/opt. Redhat didn't like that, so they installed it in /usr/something. I can't even begin to describe the problems that caused within the KDE community. Sure, maybe it was KDE's fault. Maybe it was redhat's. Either way, it was broken, and it took a long time before solutions were readily available to fix this in KDE.
/Users/gobo). The idea isn't flawed, just the current implementation (and only one or 2 problems with it off the top of my head).
/System/Programs/ and /Programs/. Whats so hard about that? Nobody is saying that what gobo has is anything close to a complete solution. Just because you can see 1 or 2 problems with what they have doesn't mean that the entire idea of doing it is flawed. That is just shortsightedness.
This doesn't work on different flavors of Linux, or *nix specifically because of this fs inconsistancy problem.
I know, technically speaking, your filesystem shouldn't have to be the same across platforms. But application writers don't design their apps to be that way most of the time. Neither do packagers. For the longest time KDE would install into
The same can be said about any large scale application for Linux. This is one problem what the LSB tried to address, but still has not been successful at.
On top of all this breakage that happens regularly, there is still the user interface inconsistancy that exists with the current classical system. There is no reason that the current system shouldn't be at minimum adapted to be consistant and intuitive, even if you don't change all the names of the directories. (name changing is just for niceness, not practicality. In solving the practical problems, they added niceness to the filesystem)
Note: none of this means I agree completely with Gobo's fs. They have obvious mistakes that should be addressed. But these are things that could be fixed in time (for example, putting root's home directory in
Nobody is saying linux should have EXACTLY what gobo has. They are saying that it needs something similar, adjusted for practicality. Maybe if you want to seperate system programs from user programs, then have
The whole point is to make a distribution that can be maintained by a normal user. Nothing fancy. Desktop users are their own system admins. They can't memorize a filesystem structure that makes no a priori sence when all they want to do is open a downloaded file with a program somewhere on their hard drive. I can tell you one thing is for sure: MacOS & Windows XP, their directory tree makes a priori sence. These are the 2 most popoular desktop OS's. They are also the best 2 for most people. Currently, *nix isn't the best, and one of its shortfalls on the desktop is hellish administration with a filesystem layout that doesn't make a priori sence. And that is the point of this distribution.
These people have been doing this for a while. You haven't spend more than 10 seconds on it. What makes you think they have not done this? And where is your evidence that what you would want to do is broken inheritantly and by design, or just because of a bug or oversight?
Simple answer: you are ranting about something you know nothing about.
I agree with you on many of your points. but...
/root -> /Users/gobo])
"If it aint broke (or at least if it aint real broke) don't fix it."
That is the problem. it is broke. You can't download an application and install it on linux. You can install an application package specifically designed for your version of your distribution. Then, many times there will be a bug in the packaging of the application because the application writer didn't intend for the application to go into a place that the packager wants it to go. So then you gotta download an updated package. This happens every single day, 365 days a year, on production systems across the world. It is called dependancy hell. It's also called non-cross platform package management. None of the distributions properly handle multiple versions of packages installed simultaneously (except maybe gentoo) and that is something that could easilly be solved on the fileysstem level, but has never been standardised.
I can sit here forever listing off stuff just like this that all roots back to the fact that most linux systems don't have consistant filesystems. Until this inconsistancy is fixed, dependancy hell will prevail. And so will filesystem bugs in packages.
And since it needs fixing, we might as well go ahead and revamp it to make it intuitive while we are at it. If you haven't noticed, this is exactly what Gobo is trying to do (though I agree that they are messing some stuff up in the process, but those are kinks waiting to be ironed out [noteably,
"One-size-fits-all is a Windows mentality, it's not, nor will it ever be, a Unix/Linux one."
You just contradicted your whole argument in your closing. One-size-fits-all is not only bad in the windows world, but it is also bad in the linux world (X, File hierachary, etc...).
The reason people bitch and complain about X is because it doesn't do what some people want. And there isn't any alternative to do what people want because there just isn't (It is out of the scope of this argument to determine why there is no competitors to X).
The same is true for the filesystem. People bitch and complain that its hard to understand, etc etc.. In fact, the linux filesystem is the single reason that package management is such a fucking BITCH across distributions. It also happens to be the root cause of great confusion to new users and application writers and application packagers. it is also the number one cause of breakage related to the packaging of applications. You have to realize that almost NOBODY (including programers, packagers, and home users) is a unix system administrator that has had 30 years to memorize obscure filesystem names, locations, and purposes for each. Having to look shit like that up (stuff you shouldn't have to look up) is tedious work. What makes it even more tedious is that every flavor of unix has a somewhat different meaning for their filesystem directories. So you are in the camp that proposes that system administrators should do more tedious work and less logical work?
Saying that you don't want Linux to be like windows doesn't change or fix these problems.
"this whole FS reshaping is a rediculous idea and goes against everything the LSB [linuxbase.org] has been tryig to fix, since there are so many deviants of GNU/Linux"
You are correct. It goes against everything the LSB has pushed for. That is because the LSB does not push for a standardised filesystem. They push for many different filesystems that the distribution decides upon, and then try to make them all compatible with eachother. LSB is the wrong approach. This has been proven in the years that the LSB has been implemented, and has existed. So far there has been not a single instance of cross platform package distribution in any shape, form or fashion, simply because the LSB allows too loose of a filesystem that any compatible distributer can change on a whim.
Maybe if LSB decided on a standard filesystem structure, this wouldn't be a problem, and people wouldn't be trying to reinvent the wheel.
Until LSB acknowledges that there is a filesystem/package management level need for multiple versions of packages to be installed simultaneously in standard locations, LSB will be irrelevant to anyone that wants to distribute packages in any form.
I don't agree that this particular distribution is solving the right problems. But they certaintly are asking the right questions. And that is what is important. They are pushing for a single standard filesystem structure, with standard locations to install files, without spreading your package across multiple disk volumes/directories.
Until this consistancy GoboLinux is pushing for happens everywhere, dependancy hell will exist on every platform that implements dependancies. It is as simple as that.
I think the root of the problem is that the LSB decided (well, got pushed into) allowing different filesystem structures between distributions. This was a mistake, and their reasoning is illogical.
/home, etc..
/opt, /usr, and /usr/local is the cause of 99% of most problems when it comes to cross platform packaging. Not only this, but with consistant and standard locations to install files that allows many versions of a package to be installed simultaneously, we can finally get rid of dependancy hell. (note: AFAIK gentoo currently takes care of multiple package versions at the package/filesystem level, nobody else will even bother nor recognize that it is even a problem.)
When every "standardised" distrubtion has the same exact rules for filesystem hierarchy, then and only then will package management be cross platform.
As it stands now, LSB has done absolutely nothing to improve consistancy between distribtuions, and only allowed them to diverge even moreso, and saying that divergance is OK for compatibility. This is a wrong assumption, and should be looked at by the LSB group.
I like the idea of improving the linux filesystem structure, but I don't believe this particular distribution has anything new to contribute. They made some bad decisions, such as user 0 in
The only way to legitimateize any filesystem used on linux is for everyone else who wants to be compatible to use it just like everyone else.
just my 2 cents (no, im not a gentoo fan, I don't even use it)
I agree with what your saying. My point is that safe-ish and not safe are effectively the same exact thing. Just because its easier to exploit non-safe systems doesn't mean that its impossible, or even difficult to exploit the safe-ish one.
In the end, I believe OS X is no more secure than running as root (except that joe user can't screw up his own machine, which isn't the real issue people are complaining about here). As it takes the Administrator user to activate the root account, and the administrator user is the default user, a virus could just as easilly get root locally if it is already installed on the administrator's account (which, may I remind you, is the default user).
I agree that a safe-ish approach is good to give people the sence of security. At least it protects the system from its users unintentional fuck up's. But that is about all it does. (And I do agree that something like this is needed to stop support nightmares, and improve stability) But I do not believe that there is anything inheritantly more secure using the safe-ish MacOS X approach.
In my eyes, a good comparison is that in order to imporve Homeland security, lets restrict our local citizens use of this land, rather than the remote terrorists. After all, that is the American Way!
What are you talking about? If it ain't root, its something like it.
/etc by the default user, which is far from non-root.
/etc by the default user.(I can't check now because I don't use macs at home) Sure, it might not be the one true "root" account, but that doesn't change the fact that it has super user powers.
we just got 3 new apples in last week. I set all 3 of them up. Every single one of them runs as root by default. What in the HELL are you talking about?
(note, non-root users shouldn't be able to access system level control pannels)
The default user has access to the entire networking configuration, hardware pannels, everything. That at bare minimum is write access to
I haven't pulled down the consol, but I'm willing to bet that I could write to any directory on the fs. And if I can't, it still doesn't change the fact that there is write access to
'I never understood how Americans can call that game "football"'
:P
Because you kick it(once or twice per game), silly
heh
"quicker than a win2k server box can be slashdotted"
;-)
But thats IMPOSSIBLE!!!!!
I never said i was against X, idiot.
I use it every day for remote desktops. XFree86. I also use it locally on Linux. Every day.
I just happen to know (unlike you) that its not optimal for local display. There are better solutions out there that are faster, more efficient, and more suited for local desktop use. Sure, XFree86 does the job. But far from optimal. The competition has proven this. XFree86 was designed to display remotely. That is what the entire X protocol is used for. It just so happens that you can use the same principles to display locally
Until you realize that XFree86 is slower than most 2d desktop rendering systems when used locally, you will be blind of the facts. Its as simple as that.
Or you could just assign IP's via DHCP according to MAC address if you wanted to give them static IPs...
Your an idiot by the simple fact that you think DHCP is a bad thing for either the provider, or users.
No matter what OS you are using, if you use DHCP, it is about 500000 times easier to setup for your users, and for the provider, and for the tech support, and for the troubleshooting. What do you suggest to use besides DHCP? PPPoE? LOL, Static IP? of course not.
Assigning static IP's to each user would be a nightmare to support. Using PPPoE just adds 30 extra steps to the setup process of each machine
I have seen a few implementations of IP Nexus and packages like it. It seems to work well. We use it campus wide here to keep public access ports secure. It works great. (DHCP every MAC that wants to connect, but don't route their traffic, then authenticate via https)
"Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?"
No.
You are missing the point. The point is to directly render all local desktops. Why on earth would you indirectly render your local desktop just because you are too lazy to implement a direct rendered model? That is the objective of DirectFB:
To implement the X protocol OVER a direct rendered local model, rather than implementing local models over X's indirect model. (note, this is how X clients work in win32))
The problem with all you X zealots that think you are god and all knowing is that you actually don't know everything. And you have proven this in your post.
"X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER"
Actually, your wrong. If you knew anything at all about how X works, you would realize this.
The reason that X is slow locally is because 2D windowing isn't directly rendered like DRI 3D or DirectFB. In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.
So insted of making XFree86 use direct rendering for local use, people are making side projects that don't implement the X protocol. Why would they? They would have to be compatible with 30 years of legacy API, which would hold the project back technically considering there are limited developers.
The problem everyone has with X is that the people who control X do not care about local performance for 2D windowing. They consider that since local methods are just special cases of the remote methods, they will be at least the same speed, or faster than remote, and that's good enough for them. The answer to everything is to put an X layer over a direct rendered model. But this is either out of the scope of the XFree86 Project, or is something they do not want to deal with (since none of them really care much about local performance).
In these shameful times, Americans cannot drink in the pub until they are 21 YEARS old. Isn't that insane?
The main reason technically speaking to keep tape is because it can withstand far far far greater G's than a hard drive. You can smash your camcorder on the sidewalk, and as long as the circuitry and gears didn't break, you can keep taping. With a hard drive, the fucker crashes on first glimpse of fall.
A camcorder with a hard drive in it is going to be more delecate, no matter how you look at it. Even if you used external FW hard drive in a backpack, you still can't be jumping up and down while using the camera.
Tape is the best media that is going to be available for camcorders in the near future. Until solid state flash chips become like CD-R in price, they aren't going to take off. Optical drives are going to kill battery life with the powerfull lazer, and the high speed motor.
What they really need to do is come up with some kind of smaller form factor tape spindles with higher density data storage. So you could fit the motors, reader/writer, and tape and everything in the size of a current 8mm cartrige.
The idea is this: which is cheaper, tape recorders/readers, optical recorders/readers, or magnetic disk recorders/readers? Tape is the answer. And its more durable under high Gs
I think the main drawback is its heat sensitivity being less than that of optical or hard drives or flash. But that is only a problem in certain climates.
I would suggest to not dismiss tape because its the 'old' kind of storage we used in the 80s and 90s. Tape is just a physical medium. We have been using disks even LONGER than tape (records)! New tape is good. It's digital. It's data redundant. It's low powered. It's high density. It's CHEAP. Don't let the misconceptions of tape being inferior because they are "old" technology slant your choice.
Not really.
If the drive is being accessed, a 1 foot drop could crash the head all over the platter. Once that happens, there's nothing you can do about it. Even on the most expensive drives, this will happen.
The solution is to spin the drives slower, and so you can have the head placed farther from the disk. This increases the force it takes to get the head to crash. They do this in laptop hard drives, but still it's not gonna withstand anywhere NEAR 10ft.
Even if you don't notice damage, it is possible for a head to damage the platter and you can get bad sectors. Nowadays, hard drives automatically hide their bad sectors by using data redundancy on the disk. So you might not notice it, but if important data is being stored in that area of the disk, its redundancy is greatly reduced, and your data is not as secure.
Of course, technically the manufacturer is supposed to detect bad sectors and mark them as such(internally in the HDD, the OS has no knowledge of this), but not many MFG's do that in the real practice in the IDE world because they hide it with data redundancy.
Doubtful, but could depend on state.
Most states do not require your business to be in a business zoned space to get a business license. In fact, most zoning regulations allow home offices and home businesses in residential zoned locations. The zone regulations are ONLY FOR TRAFFIC. If you are a retail front, you need to be zoned that way. If you are a single software business owner who R&D's in his basement and sells on the internet and you don't get shipments all the time like a real business would, you don't worry about zoning. Home offices and Home businesses are legal, legitimate, and perfectly fine in residential zoned areas.
That is why its called a home business.
From Dictionary.com:
"emulate: 3. Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system. "
I hope you know, that by definition, an emulator is an implementation of an interface. In this case, and Application Programing Interface (API). There is nothing special about WINE that makes it not an emulator. Sure, it may or may not have more or less features than the reference implementation. But that is beside the point. It is one, by the very definition of emulation. WINE Is Not an Emulator is just another GNUism. just like LAME Ain't an Mp3 Encoder(which it is).
Just thought you might wanna know that before making such silly claims as above.
Agreed.
I too agree that the BSDL is better for government funding. This means that anybody can use it for anything, no matter what. You can't do that with the GPL. The BSDL is closer to the public domain than the GPL, and that is why it IMO is considered better for that type of stuff.
I think that although the GPL is less likely to be exploited by big monopolies, it goes against the principle of government funding. In the end, my ultimate view is that we should modify the government's BSD like license to state that it is illegal for a monopoly to use BSDL code in any product. I haven't thought it through very lengthly, so I havent though of any holes in this idea. But I believe that monopolies don't have rights, they have restrictions (morally). And if you are a monopoly, you should not have the right to what the public spent their hard earned money on.
I see your point, but my example of cars and drugs are closer than you realize...
I will attempt to compare the costs of each of 4 industries I mentioned (software, music/movies,drugs, cars*).
1) Negligable reproduction cost *
2) Negligable raw materials cost *
3) Very high R&D costs
4) Slightly high QA costs (including FDA approvals)
4) Advertising cost
5) Negligable market value/inflation/deflation cost of manufacturered yet unsold product cost
* does not apply to cars
(note, these apply to just about everything in the computer industry, except printers which is more like cars than computers. Even CPU's and memory can be considered an "IP" driven market)
Basically, any IP driven market is comparable to the above. The difference that software has when compared to the other industries is that there are significantly more people capable of producing quality software than there are bioligists/chemists and musicians to produce drugs and music/movies. For this reason, software has much more competition then the other two main IP driven markets presented above.
The reason my first comparison was about cars is because, if you change classifications and consider labor, raw materials, and equipment costs as "fixed costs of the product", then the IP driven markets and raw materials driven markets merge into the same thing.
I compensated for this by including the factory and raw materials cost into the "government grant" in the hypothetical situation. But I will agree that since replication costs are the most significant part of a car, and the least significant part of IP driven markets, my example is somewhat invalid.
However, Drugs, Music, Movies, and Software are still (in my book) all IP driven markets that have negligable replication costs. The drug companies and entertainment industries have already proven what kind of monopoly can be had on IP driven markets by lobbying congress with billions of dollars a year to keep marijuana and other effective alternatives to manufactured drugs outlawed, government R&D grants expanded, outlawing devices that are capable of replicating raw data that has been negligably encrypted, and letting false advertising and trademark violations (illegal use of the Compact Disk trademark to manufacture non-compliant CDs) and anti-competitive behaviour reign in these industries. I think the reason software isn't already in that state is because its market(for the mass public) is significantly newer than drugs and entertainment, and not all of the monopolies have firmly pushed out everyone and lobbied congress for laws which do the same for them (but you have to admit that some companies such as MS have already started doing this).
I think that a BSD type license has the potential of supplementing a RIAA/MPAA/DrugCompany-like monopoly in the software industry moreso than a GPL. However, I am still standing by the fact that I believe the BSD license has better usefullnesses in certain circumstances, and the GPL others. I am not a GPL proponent, nor a BSD proponent. I also fail to see where I am confused on the issues. I am mearly pointing out other viewpoints that you have failed to mention that tell the opposite side of the story you have told.
I do not believe that the BSD Core group could ever "close" the BSD source. I am mearly saying that it is technically possible for a hostile government sanctioned (through lobbying) illegal monopoly (similar to the RIAA,MPAA, and Drug companies) to effectively stop the use of BSDL software if they so desired by not allowing competition (even 'free' products) into the marketplace.
Microsoft has shown how this is possible by monopolizing the Office Suite and Desktop OS markets with proprietary and closed file formats and protocols. I just don't think Microsoft is completely there (at least not yet, if ever).
I agree with you mostly.
My main point is that BSD is easier to exploit through illegal (but government approved) practices (for example: microsoft).
Obviously, you must be doing wrong to do as I have described. My main point was that it would be impossible for someone to exploit is as above using GPL, but much easier to do with something like BSD.
I don't want to say that we should shy away from BSDL, but I was just giving an alternative viewpoint that I think is equally as valid and sound as the Pro BSDL argument.
All it takes is a hostile monopoly, and no "startup" can get into the market, no matter how little value the monopoly adds.
I think drug companies are a prime example. And very real at that. It is IP they have, not manufacturing processes, materials cost, etc.. They don't even pay for most of the R&D, it is all government grants. In fact, they spend less per year on R&D and manufacturing than they do on advertising and lawyers.(very similar to the RIAA and MPAA) The only difference between my hypothetical software example and the drug companies is that patent law is what determines who can use the IP, and not copyright law.
Of course, when the government gave them grants, they didn't have any restrictions on who owns the IP (they kept it, not the public). In the OpenBSD case, they were granting that the public gets access to the IP that was created with the money. So there are slight differences that are hard to weigh when looking at this case.
Note: I'm not a GPL proponent, but I'm also not a BSD proponent. I'm just trying to give you yet another POV that you may not have thought of.
Ok, so let me give you this little scenerio for a second..
So Ford and GM are making all these cars. Some open source car design starts up. All these mechanical engineers are designing this car engine and body in their spare time on the internet. Eventually, the design team (on the internet) decides they need more money to be able to build a factory to manufactur this basic car that they say will be cheaper for consumers.
So they get a government grant. They build the factory, hire factory workers, hire full time engineers to make more improvements on the design. Soon, you have a working car with a decent design, for pretty good price. The public just foot the bill, but its a Good Thing for the public because now they have this car for cheap! Right?
Wrong.
Since these cars are "BSD" they are cheap to everyone. Including Ford and GM. They are cheap because the government foot the bill for the factory and the engineering designs. Now Ford and GM get all these cheap cars, spend a slight amount of money, and improve it, can it to consumers, and profit to fuck, all while the tax payers foot the bill for their R&D, factory costs, and labor.
On the other hand, if these cars were more restricted... Somehow make a rule that doesn't allow a company to rebag the governments car with a few bells and whistles for a profit, while maintaining a monopoly on all cars (a monopoly which may or may not be granted by the government, ie: MS). If a rule somewhat like this were made, then taxpayers wouldn't be footing the R&D and manufacture bill for big coporations that own monopolies on said product.
But then again, a grose, shameful, and very real example of all this in today's world is the medical drug industry. We already have this, but insted of copyrights, its patents. Where the government spends more R&D dollars on drugs than drug companies (which spend more on advertising than R&D)
The end result is the same in all circumstances. The rich people who are making money off these coporations profit more, while everyone else pays for the R&D that is making him wealthier than the rest. So while BSD might be a good thing in general, I do think it is more suceptable to being exploited by big monopolies such as microsoft.
Natalie's Hot Grits is just a slashdotism. I'm not trying to pretend to be female. Hope that clears it up :P