Lulznix project needs your help. We need some avid linux users to help the chan linux project.
We need feedback on what you guys want in the distro such as features, programs etc.
Even if you dont know much about linux, you can still help out in other ideas such as, what you want in the distro etc. Also help in the graphics design area.
Make sure to digg this to so it can have some advertisement: http://digg.com/linux_unix/Lulznix
You can help me out by explaining why anybody would use crap like that.
there are loads of reasons. but they are on 7chan
>>3
So in other words they're all moronic?
>>2
Its not Ubuntu.
But since its not Slackware, I'll never touch it.
This is probably the biggest waste of time and bytes in the history of mankind. Shouldn't you people be out there posting "bump" and "moar"?
>>5
Can't really tell whether you're a moron or just a parody of one. I'll opt for the latter.
How come everything 7chan does is huge fail?
Hahahah, phpBB. Good job, "anonymous". No need to mock you any more, you've done the job better than any of us could.
The only innovations in Linux these days are distributions which shun the "traditional" directory layout. For instance, GoboLinux.
If you're not doing anything that revolutionary, don't create more distros. Contribute your time and effort to an existing distro instead, more people will use your product then, and generally you won't be wasting your time.
>>9
Yeah, because the first thing on the mind of everyone who switches to Windows is DIRECTORY LAYOUT.
Useless "innovation".
It's a well recognized problem (by everybody except fanboys) that the Unix directory structure is completely outdated and non-sensical, and changing it would bring immediate and obvious benefits. OS X did, and with good reason.
As for >>1, he'll soon notice that a joke is not enough to inspire anyone to do any actual work, and his project will slowly die out after the initial burst of activity.
What the hell kind of normal user ever SEES the directory layout?
"Lots of people have to look at it every day in order to..." Well then, fix that. If you want to innovate.
Directory layout = low-level OS implementation detail that should not matter to anyone. Organizing data in hierarchies is dumb anyway. Look at music players with libraries (Foobar on Windows, Amarok on Linux, iTunes on Mac) where you don't even see the filename usually -- that's how it should be done.
I'm aware that there was a long dumb debate on this board about the Linux directory layout, like, what, a year ago? But if directory layout even matters, except for system programmers (who can deal, kthx), you've fucked up. What are you going to suggest next? Overhaul the C programming language to be more friendly to newbies?
On the Mac, you see it all the time. Because it is actually designed so that it can be seen. The only reason you want to hide the directory structure as a low-level OS implementation detail is because you can't do anything else with it! It's so hopelessly convoluted that it becomes a low-level implementation detail, instead of a way for the user to interact with his computer.
To be exact, though, OS X lives a bit of a double life - it contains both the legacy Unix structure, which is hidden, and the new Mac OS structure, which is shown.
Wait, what's wrong with the standard UNIX directory structure?
It's not so much a "structure" as an explosion of files across the file system. A single app will have files pretty much all over, making installation needlessly difficult and uninstallation nearly impossible.
>>16
This is something generally solved by the abstraction of programs and all their files into "packages" handled by a "package manager," which deals with any manipulation of the package (installation, removal, updating, &c.).
The package manager is a symptom. Just because it handles the problem doesn't mean there is no problem.
If the problem's abstracted away so that a normal user does not ever deal with it then it isn't a problem at all.
Why only benefit normal users? Don't advanced users deserve better usability also?
It brings many new problems instead. It is certainly not a good solution by any measure. It's a horrible kludge over a horrible problem, and it hurts the platform by making people think the original problem doesn't exist, just like you.
(Problems: harder to distribute software for third parties, tends to break when users install software without the package manager, &c &c)
>>14
I'm speechless.
That is exactly what >>13 said, the legacy directory structure should not be visible, thus it should not matter.
If you want to replace it with another hierarchy, OK, but I think a flat, searchable collection with metadata and tags makes more sense for the future.
But goodness, you don't have to actually replace what is effectively hidden... as you just frickin' agreed!
You misunderstand. OS X does not rely much on the legacy structure. You could probably delete it entirely and the OS would still run just fine (although likely not boot). It really is legacy, in that most Mac OS apps do not use it. They use an entirely different hierarchy, which is very much visible. Applications, libraries, OS components, they all live in the new one.
The same is not true of any other Unix system I know.
Your concern for directory layout seems to be based on an assumption that the most user-friendly way to interact with a computer is using a hierarchical directory structure.
Why?
I disagree. I think whether it's /usr/bin, /bin, /Applications, C:\Program Files, or whatever, if you're putting programs in a hierarchical directory structure you are still firmly stuck in Geek Land.
Shared libraries. How are you supposed to minimise redundancy if you keep multiple copies of the same library, keep the libraries updated if there is multiple copies of the same library without some sort of tracking mechanism such as a one used in a packaging manager?
>>19
While arguably true, that reminds me of the broken window fallacy.
>>25
One possibility: don't keep around multiple copies of the same library.
>>25 A library manager could do that.
Consider one that took the SHA512 hash of the library, with the SHA512 hash of the interfaces (say what nm says is exported) and copy it into /system-library-cache/XXXYYZZ -- modifying the dynamic linker to do this before mmaping it would allow you to share libraries without worrying about where they are.
Why is minimizing redundancy so important? Disk space is cheap. Redundancy can easily be sacrificed for other more important factors.
He still has a point about keeping libraries up to date, though. I hesitate to think how many Windows programs are still insecure because of those zlib vulnerabilities ages ago... Since they each built in a copy of zlib.
>>29
Space in RAM? Loading the same library twice is stupid.
That's fine and all, but there are tons and tons of libraries that are on average only used by one program residing in memory at one time.
If not for the stupid name, it might have half a chance at being a good Linux distro aimed toward privacy.
Kinda like OpenBSD, but Linux.
i kind of like the idea. and i dig tuxkip
>>32
Indeed, which is why hard linking is a great idea.
>>36
uh no. it still has the same problem as multiple copies of a library. you'd need gigs of memory to use kde or gnome if you ran statically linked programs that depend on those libs
Are you sure? Hard-linked files have the same inode, which means mmap() would share the same pages.
>>38
I was thinking of static linking. My mistake.
>>31
Sometimes you need to keep different versions of the same library around. API changes and that sort of thing.
>>40
Customarily, such changes only happen for major version increments, and well-maintained programs are usually updated to keep up with the new API version.
Of course this doesn't always happen and so you'll end up with a ton of different versions of things anyway.
AHHHHH MOTHERLAND!!!!
www.sovietrussia.org
>>40 Those different versions make them not the same library, and hence would not be hard-linked.
All the more reason to hash the libraries...
mona os is superior.
it is made of moon language and scheme. and not loozdix.
>>42
go away
Mona OS sucks, it doesn't even have jisshin/kashin model.