View Full Version : I like this...Looks very promising
Hello everyone,
A tiny bit of background first, I have been a Linux user since kernel 2.0.30, and run FreeBSD/NetBSD for small router/servers.
I really think this looks promising, seeing as everyone here has the right idea about going through with a project like this.
Lindows did the same thing, and went about it poorly. I wonder why they are still around with the subscription based service.
I cant wait to see computers at walmart with PCBSD ... ok kidding...
Anyway I have a couple of opinions I wanted to give. And some questions, since I have not read any of the forum yet and not much of the FAQs.
So lets get started.
#1. This project will need some media exposure, otherwise it may fade away like EkkoBSD. I would like to see something like this "strive" it looks very promising.
#2. Like I stated I have not read the FAQS yet, but is there a structure for creating your installer packages?
#3. Integration with wine is going to be a must to provide a compatability level for people new to PCBSD, also maybe include cedega or the cvs compiled open source version..
#4. I know some people wont like this since its the "new age" with ultra fast computers that LOVE kde4, but XFCE4 + Rox Filer will do the job and use a smaller memory footprint for a desktop manager. I like KDE dont get me wrong at all. But as an idea, some time in the future of your project it could be used as an alternative for systems with less memory and hard disk space. KDE Atleast on debian will take over 300mb to install the desktop environment.
-- This means you could install the system on a 386/40mhz with a Math Co-processor (FPU) on a system with 32mb of ram
#5. Drivers... the default FreeBSD kernel provides support for A lot of common hardware, Im uncertain as to if it has loadable kernel module support. I assume yes. What would be nice to see is a graphical configuration tool for loading/detecting/configuring lkm's for different drivers.
#6. 4GB of storage is A lot to use, but then again KDE is huge...
#7. Eventually someone needs to build an automagic installer for transcode/mplayer/dvd::rip, K3B...
#8. Is anyone considering using -static binarys, even though it will increase the size, you could do away with broken libraries/software when upgrading a system to a new release.
#9. Since this is a workstation version, is local security planned. If possible I believe the system should be set up in such a way to use chmod 4750 on setuid files not needed, using a "power-users" / "root" / "users" groups for such security, and also auditing of packages for flaws and other issues. Or is it going to be a group oriented project where different individuals submit packages with no auditing?
#10. Auto-Magic SMB configuration/Printer configuration... this is a must to compete with windows, as well as Auto-Magic network configuration. Scanners, Cameras, etc... For what is supported through the usb/etc.
#11. Compiler optimizations for the default kernel/software packages? Is this being done?
#12. Again, I really like the idea and the concept, the little reading ive done is really making this project look promising. The features look like they are being implemented in a good sensible fashion. I hope it continues that way and becomes a popular choice.
I will definately try this out on one of my systems some time this week and take a closer peek at it. There may be a few things I could contribute.
Hello everyone,
#4. I know some people wont like this since its the "new age" with ultra fast computers that LOVE kde4, but XFCE4 + Rox Filer will do the job and use a smaller memory footprint for a desktop manager. I like KDE dont get me wrong at all. But as an idea, some time in the future of your project it could be used as an alternative for systems with less memory and hard disk space. KDE Atleast on debian will take over 300mb to install the desktop environment.
I think kde could be hacked, we can remove unnecesary parts, we can modify it and if properly compiled it can be speeded up.
#8. Is anyone considering using -static binarys, even though it will increase the size, you could do away with broken libraries/software when upgrading a system to a new release.
It could be a great ideea to use some static libraries. Maybe people who make pbi's can make the effort to compile the packages and link against static libraries.
As a completion I propose a Big Media Library to group Mesa, SDL, libjpeg, libpng, libavifile, libaudiofile, etc. so in place of 1000+ media libraries we end up with one biga happy library. Preety much like Direct X.
lazyilmaz
06-07-2005, 09:47 AM
Good idea Dixy :) I think we should do something like this.
i'm voting for your idea dixie
dean_fry
06-07-2005, 01:51 PM
I think kde could be hacked, we can remove unnecesary parts, we can modify it and if properly compiled it can be speeded up.
i second that 100%
I have seen upgraded librarys break precompiled binarys. I have seen breakage from librarys being named for instance, the original libelite-1.2.3 then someone upgrades it to 1.2.8 and the old library is removed but a binary is linked to 1.2.3. So what would someone do in this case. just have a libfile.0? just have a libfile.1.2 and not have 3 or 4 libfiles-1.x.x?
Or just make one big liball.1.x / liball.0 containing a complete API/ABI? interface for every library used on the system. As proposed?
What I am trying to get at is the project is going to need to maintain compatability with older pre-compiled binarys, such as with windows.
This is really something for the developers to discuss. But what is missing in certain linux distributions is compatability when certain libraries get upgraded it tends to break old binarys like I stated.
I do think a bundle of addon libraries would be a good idea, then build the pbi's based upon that bundle. That way upgrades of the libraries could be done, and an attempt to maintain compatability could be done with each upgrade to the library bundle pbi.
Hello everyone,
#4. I know some people wont like this since its the "new age" with ultra fast computers that LOVE kde4, but XFCE4 + Rox Filer will do the job and use a smaller memory footprint for a desktop manager. I like KDE dont get me wrong at all. But as an idea, some time in the future of your project it could be used as an alternative for systems with less memory and hard disk space. KDE Atleast on debian will take over 300mb to install the desktop environment.
I think kde could be hacked, we can remove unnecesary parts, we can modify it and if properly compiled it can be speeded up.
#8. Is anyone considering using -static binarys, even though it will increase the size, you could do away with broken libraries/software when upgrading a system to a new release.
It could be a great ideea to use some static libraries. Maybe people who make pbi's can make the effort to compile the packages and link against static libraries.
As a completion I propose a Big Media Library to group Mesa, SDL, libjpeg, libpng, libavifile, libaudiofile, etc. so in place of 1000+ media libraries we end up with one biga happy library. Preety much like Direct X.
The proposal is to eliminate the equivilent of "dll hell", excess copys of librarys and excess installation of packages and reduce breakage based on inconsistant versions and linking to inconsistant versions.
From an end-users standpoint, they want it to "just work". Reducing the size is also a good consideration.
But what is missing in certain linux distributions is compatability when certain libraries get upgraded it tends to break old binarys like I stated.
If we have one Big Media Library, the media apps linked against this library won't suffer a bit. It's just when you've upgraded from DirectX 8 to DirectX 9 in windoze.
lazyilmaz
06-07-2005, 06:17 PM
Here's another "stupid" idea. Like i said on another thread (http://www.pcbsd.com/forums/viewtopic.php?t=390) the directory structure should be simplified. This can be done the OSX way. There should be a folder called "Library"in the root. PCBSD should be shipped by default with the most used library's in this folder. Then the system should create a "database" of this library's. In this "database" you should put the names, versions etc... of the library's. The PBI installer should work closely with this database. This doesn't mean that you should create the pbi packages without the dependencies, it means that the installer should first look in the database and when it's sees that the library's are already installed, then he should use them instead of installing them again. Whenever a new apllication will be installed the "database" should be updated. This should keep the system "clean" without any dependency problems.
I also send Kris an email about a custom GUI based on KDE. He thinks it's a good idea but he didn't do anything with KDE and he adviced me to ask this on the forum. So if there are any people here which knows how to modify KDE and create a custom GUI for PCBSD then we should start working on it.
I also send Kris an email about a custom GUI based on KDE. He thinks it's a good idea but he didn't do anything with KDE and he adviced me to ask this on the forum. So if there are any people here which knows how to modify KDE and create a custom GUI for PCBSD then we should start working on it.
I also mailed Kris about that and I am pending his consent. I am glad that there are others which thinks like me and maybe we'll do a great job hacking kde. We can get a place to develop our KIM - IMproved Kde such as sourceforge.net or berlios.de. Just wait for kris's response, form a team, and we are ready to go. Beside programmers and people with Unix knowledge we will need good designers and I know you are good at that.
I know we wil get the attention of open source folks with our KIM. So if 8.0 has codename Vancouver let's name the first KIM release "Camel". Why Camel? Ask beduins - it is fast, reliable, resistant and doesn't need fuel (10 liters of water will do).
Those are actually excellent proposals, I dont know how OSX handles libraries since I have not seen it in action.
From what you stated, i understand is OSX handle /Library by providing many different versions of certain librarys as needed, then keeps a centralized database aka "Registry" of these librarys, then the programs read from this database/Registry of librarys to determine which one is appropriate for its execution?
Correct me if this is how OSX operates...
Or you could have for instance libelite.0, when a program needs to access the library libelite.0 is a type of "wrapper" library which will determine which version of libelite the program requires... such as libelite-1.2 or libelite-2.1. The same could be done if libc6 had major changes which broke older software.
"-static is sometimes nice"
Modification of KDE would be a good idea but KDE is enormous, the code takes around 4 hours to compile on a Athon 2200. If this is done, which would be rather nice to see you would have the drawbacks of having to use multiple kde librarys eventually once a new kde was released, unless the source modification was done to the later version as well. It would be a large development effort.
At this time this early in the PCBSD project I dont see that as a short-term reality without the publicity and interest in the system from a large user base. There arent enough developers interested in that.
I would focus more on the following in the short term
1. making a good solid library system that doesnt "break" over time.
2. provide a development environment that fits to the conformation of the system structure to encourage development on a stable platform base.
3. documentation on the pbi system.
4. continue to use the freebsd kernel without forking off, while keeping the kernel up to date
5. 1.0 Release should contain a stable library system that differs from standard Linux/FreeBSD/GNU style in the way mentioned earlier to prevent breakage
6. Publicity when the system becomes stable
7. since there is binary compatability with linux, the use of Linux games will encourage the younger population to utilize the system -- see publicity
8. KDE provides some control over your print/display/control panel functions
but a complete graphical control panel function would motivate people to use the system....
9. Eventually get to the point of modifying kde or making a custom GUI fork from kde, or even a completely seperate interface once the other elements are in place to provide the proper system integrity. Possibly even completely forking off from freebsd to become a seperate operating system entirely based upon the original codebase, but DO not do this unless the project has become large enough to encourage development
10. From here the sky is the limit including profit from telephone based support, shelve sales in Best Buy,CompUSA,Circuit City, even walmart.
But always provide the system for free off the internet, and the pbi library for free.
It will be a big smack in the face to Microsoft, IBM, Novell, Sun, Even Apple, to have a freely available highly stable end user system with ease of use of Windows, and the ability to operate complex applications and software like a standard unix like system. There could be PCBSD Workstation PCBSD Server PCBSD Enterprise Server which could bring a large profit margin and dominate Microsofts domain if the ease of configuration is still there with the server daemons.
I am not a member of the PCBSD project development team but I do think that some sort of library database/packaging would be something that needs major focus on to provide the ease of upgrading like with windows. A large user base could be generated based upon that, so as to not break older pbi packages, and provide an upgrade path for future and current users of PCBSD.
Here's another "stupid" idea. Like i said on another thread (http://www.pcbsd.com/forums/viewtopic.php?t=390) the directory structure should be simplified. This can be done the OSX way. There should be a folder called "Library"in the root. PCBSD should be shipped by default with the most used library's in this folder. Then the system should create a "database" of this library's. In this "database" you should put the names, versions etc... of the library's. The PBI installer should work closely with this database. This doesn't mean that you should create the pbi packages without the dependencies, it means that the installer should first look in the database and when it's sees that the library's are already installed, then he should use them instead of installing them again. Whenever a new apllication will be installed the "database" should be updated. This should keep the system "clean" without any dependency problems.
I also send Kris an email about a custom GUI based on KDE. He thinks it's a good idea but he didn't do anything with KDE and he adviced me to ask this on the forum. So if there are any people here which knows how to modify KDE and create a custom GUI for PCBSD then we should start working on it.
Modification of KDE would be a good idea but KDE is enormous, the code takes around 4 hours to compile on a Athon 2200. PCBSD then we should start working on it.
Linux was the first free OS. Linux is a thousand times more complicated that Kde but, hey it's here and it's done, and it's hacked every day. Regardless compile time. As for the time compiling KIM, we will use CVS or SVN, and will take just a moment. And I hope that after we will done KIM the whole package will compile in less than 15 minutes.
Sounds good! Keep it up! :P
Its not a bad idea, the timing isnt right unless a large devoted development team is established.
I would personally like to see it but the focus needs to be on usability and library issues IMO before the massive KDE project.
Plan ahead on the issues that have plagued everyone so it doesnt happen again.
BTW Linux first free os? wasnt it 386BSD which spawned Net/Free/Open*BSD and had the novell lawsuit against all distributions for proprietary code used from at&t/bell labs which resulted removal of like 3 out of 20,000 files of source code?
Or was it Minix, i dont think linux was the first, oh well.
Modification of KDE would be a good idea but KDE is enormous, the code takes around 4 hours to compile on a Athon 2200. PCBSD then we should start working on it.
Linux was the first free OS. Linux is a thousand times more complicated that Kde but, hey it's here and it's done, and it's hacked every day. Regardless compile time. As for the time compiling KIM, we will use CVS or SVN, and will take just a moment. And I hope that after we will done KIM the whole package will compile in less than 15 minutes.
BTW Linux first free os? wasnt it 386BSD which spawned Net/Free/Open*BSD and had the novell lawsuit against all distributions for proprietary code used from at&t/bell labs which resulted removal of like 3 out of 20,000 files of source code?
Or was it Minix, i dont think linux was the first, oh well.
Yes if you take things like this. Minix was the first free os that I know of. Are you running minix right now?
Linus developed his kernel fast. If we had to wait for GNU Hurd.. University of California has some lawsuits regarding Unix and BSD. So, Linux it's the first free *nix that we have. And *Bsd it's not Unix. Unix it's what says an unnamed consortium to be.
youlle
06-07-2005, 08:48 PM
BSD is UNIX in all but TM, as it is a direct decendant of AT&T UNIX, and to say other wise is just in-correct, BSD is NOT a UNIX™, but BSD is a UNIX, because of its decention from the AT&T UNIX code base
lazyilmaz
06-07-2005, 08:57 PM
Those are actually excellent proposals, I dont know how OSX handles libraries since I have not seen it in action.
From what you stated, i understand is OSX handle /Library by providing many different versions of certain librarys as needed, then keeps a centralized database aka "Registry" of these librarys, then the programs read from this database/Registry of librarys to determine which one is appropriate for its execution?
Correct me if this is how OSX operates...
Or you could have for instance libelite.0, when a program needs to access the library libelite.0 is a type of "wrapper" library which will determine which version of libelite the program requires... such as libelite-1.2 or libelite-2.1. The same could be done if libc6 had major changes which broke older software.
That's exactly what i mean, but i don't know either how OSX works :D
I just saw a picture of the root of a OSX system, like this one
http://www.ucs.ed.ac.uk/usd/cts/ol/os/m ... ucture.jpg (http://www.ucs.ed.ac.uk/usd/cts/ol/os/mac_osx/Panther/about/images/OSX_folder_structure.jpg)
I saw their was a Library folder and thought why not put all the library's in one folder(s) and let the system/applications know they are there using a databsase/registry. I thougt this could be a good idea :)
dean_fry
06-07-2005, 09:05 PM
yeah this looks great!! instead of application (macos9) we could have application (linux)...
the rest can be the same!!
hope pcbsd embraces this approach!!!
[quote="youlle"]BSD is UNIX in all but TM, as it is a direct decendant of AT&T UNIX, and to say other wise is just in-correct, BSD is NOT a UNIX™, but BSD is a UNIX, because of its decention from the AT&T UNIX code base[/quote ]
I have to disappoint you. Bsd (looking at source tree) it's not unix at all. Unixes - the orthodox way- are those derived from System V or System III (AT&T source). Anyway you need right now an unnamed consortium to declare you as a Unix.
I have to disappoint you. Bsd (looking at source tree) it's not unix at all. Unixes - the orthodox way- are those derived from System V or System III (AT&T source). Anyway you need right now an unnamed consortium to declare you as a Unix.
I'm going to split some hairs and expand on this a bit. BSD, depending on the version, is derived from either Version 6 or Version 7 Unix, which ran on the PDP-11. It was initially released as an add-on to the AT&T Unix code (which was available for licensing at a reasonable cost to Universities, at least), and was particularly attractive once BSD supported virtual memory on the VAX 11/780.
Both Version 6 and Version 7 predated Sys III or V by quite some time, and these are still "real" Unix. So a PDP-11 that still runs Version 7 is still real Unix, even though it precedes Sys III or V.
Over the years as the cost of the Unix license increased, the CSRG at Berkeley increasingly replaced AT&T code with their own, so that it could be released without an AT&T license. The legal entanglements culminated in the 1994 settlement with AT&T where the few bits that remained were either removed or had the Licensing language added.
Yes, you do need the consortium to declare something "Unix." I'm certain that FreeBSD could be certified, but there either is no money for the task, or no desire to do so.
So BSD derives directly from the group most associated with Unix outside of AT&T. It has a noble lineage that is very intertwined with Unix. It has essentially no code left from Thompson and Ritchie or the rest of the early AT&T crew, but I don't know how much of that remains anyway, even in SCO's or Sun's products. I think it is fair to say that it is a lot closer to AT&T Unix than is Linux, which began life as the Minix kernel, a Unix clone started for the Intel 386.
As an aside, you may find it amusing to read about the hardware requirements for these early Unix systems. From my Version 7 Programmer's Manual (copyrighted in 1979 and 1983) it states:
The 7th edition Unix operating system runs on a DEC PDP-11/45 or 11/70 with at least the following equipment:
128K to 2M words of managed memory; parity not used.
disk: RP03, RP04, RP06, RK05 (more than 1 RK05) or equivalent.
console typewriter.
clock: KW11-L or KW11-P.
It goes on with recommended equipment and the format of the distribution tape (9-track), but you get the idea. For reference, the RP03 had a capacity of 40 megabytes (not Gigabytes); recall that a word on the PDP-11 was 16 bits. This was an extremely powerful machine in its day.
In the end, I don't think it matters much whether or not the *BSDs or the GNU/Linux of today are "real" Unix. They all have their market share.
DrJ
Over the years as the cost of the Unix license increased, the CSRG at Berkeley increasingly replaced AT&T code with their own
DrJ
That's the problem: "biologically" Unix inherits the At&T inheritance. BSD does not. Linux does not. They're not "DNA proof" unices, they even don't deserve to call Unix, but they are better.
I guess this is how it stands.
Linux is the first Free operating system that has not been attacked by lawsuits.
386BSD is essentially part of the AT&T unix, it contained properitary bits of code which is why it was changed to 4.4BSD-Lite even before 386BSD it was licensed from AT&T
I have used minix for a 286 I believe, not a great peice of work.
Anyway, I dont want to start a war, I was just curious if I missed something.
BTW Linux first free os? wasnt it 386BSD which spawned Net/Free/Open*BSD and had the novell lawsuit against all distributions for proprietary code used from at&t/bell labs which resulted removal of like 3 out of 20,000 files of source code?
Or was it Minix, i dont think linux was the first, oh well.
Yes if you take things like this. Minix was the first free os that I know of. Are you running minix right now?
Linus developed his kernel fast. If we had to wait for GNU Hurd.. University of California has some lawsuits regarding Unix and BSD. So, Linux it's the first free *nix that we have. And *Bsd it's not Unix. Unix it's what says an unnamed consortium to be.
You are all right. You are just sayng that BSD's not Unix.
I don't think that's quite right.
Linux has been challenged legally, or at least the deep pockets that use Linux have (such as IBM). You could say that the *BSDs are the first Unix-like OSSs that no longer have legal encumberances about its supposed use of the Unix code base. SCO's legal actions seem to be fizzling out, but I don't think the final ruling in their suit against IBM has been issued.
IIRC, both 386BSD and BSD/OS were launched when it was thought that all of the AT&T code was cleansed, so they were released without an AT&T license.
After the lawsuit settled, two forms of BSD were released: one without AT&T code (4.4BSD-Lite) and one with (which required a Unix license).
Neither Linux or *BSD are certified as being Unix, so they aren't Unix. That's somewhat arbitrary, as the old Version 7 Unix probably could not be certified as being Unix, but it is real Unix, at least according to its geneology and original license. There's probably not many of these machines around...
Still, when I'm speaking generally with somewhat non-technical people, I usually say I'm running Unix (which they have heard of) to distinguish it from Linux. They usually have not heard of the *BSDs, so unless they are really interested (rare), the explanation suffices for my purposes.
DrJ
[edit for typos -- there are probably more]
See AT&T vs University of California.
See AT&T vs University of California.
For what?
DrJ
scottro
06-08-2005, 02:12 AM
It was too much of a pain to put quote marks around your paragraphs vs mine, but it should be pretty clear as yours have the # and a question number before them. :)
I cant wait to see computers at walmart with PCBSD ... ok kidding...
S: It could happen. When Gentoo first began, the mailing list had about 2 posts a day--I remember a friend and I trying to work out a problem and him writing, "It's not well-documented yet."
Anyway I have a couple of opinions I wanted to give. And some questions, since I have not read any of the forum yet and not much of the FAQs.
So lets get started.
#1. This project will need some media exposure, otherwise it may fade away like EkkoBSD. I would like to see something like this "strive" it looks very promising.
S: It was distrowatch-ed--not quite the same as being slashdotted, but it brought a great deal of attention to the O/S, including some well known folks like Dru Lavigne reviewing it on O'Reilly's site.
It seems to be growing daily.
#2. Like I stated I have not read the FAQS yet, but is there a structure for creating your installer packages?
Yes. :)
#3. Integration with wine is going to be a must to provide a compatability level for people new to PCBSD, also maybe include cedega or the cvs compiled open source version..
Haven't used wine on any of the well known desktop distros, but is it integrated to the point of crossover office?
I think that this is something for the future--in a soon to be released
interview with Kris, he comments that at this point, he's just trying to get it together, and there are endless possibilities.
I think too that as the user base grows (and it seems to be growing quickly) many people will begin (and have begun, actually) contributing. At that point, it will be more feasible for someone to work on integrating wine.
#4. I know some people wont like this since its the "new age" with ultra fast computers that LOVE kde4, but XFCE4 + Rox Filer will do the job
This one is actually in one of the faqs (or was, I know they've been changed a bit). He chose KDE because it was one of the easiest for the MS or Mac user to comprehend. Again, I think as the user base (and, as a natural progression, the developer base) grows, you'll see things like this.
#5. Drivers... the default FreeBSD kernel provides support for A lot of common hardware, Im uncertain as to if it has loadable kernel module support. I assume yes.
In this case, assuming did not make an a** of you and me. :) Yes, the kernel does have loadable modules, done a little differently than it is in LInux.
#7. Eventually someone needs to build an automagic installer for transcode/mplayer/dvd::rip, K3B...
Again as mentioned in the soon-to-be-release interview, he is hoping to do things like that.
#8. Is anyone considering using -static binarys, even though it will increase the size, you could do away with broken libraries/software when upgrading a system to a new release.
I dunno. :)
#10. Auto-Magic SMB configuration/Printer configuration... this is a must to compete with windows, as well as Auto-Magic network configuration. Scanners, Cameras, etc... For what is supported through the usb/etc.
Good luck. Even Mac printing is often horrible when compared to MS. It's one thing that MS does right. CUPS (Can't Usually Print Stuff) is getting better, but still has to improve.
We *nix admins wind up using it anyway, (usually in conjunction with samba for our MS clients) and I will certainly say it's come a long way in the last few years, but printing in Unix is still non-trivial.
#11. Compiler optimizations for the default kernel/software packages? Is this being done?
At this point, although the target audience isn't quite Aunt Tilly, it is probably aimed more at the person newer to the BSDs. Those of us who are a bit more familiar with the BSD's know how to optimize compiler options (which can sometimes break other things, btw) and the like.
Do keep in mind that this is a very new O/S. I suspect that tweaks like this will gradually make their appearance, but it is really aimed more at the end user, who would be better off NOT tweaking, because then it will break something else that they won't know how to fix.
#12. Again, I really like the idea and the concept, the little reading ive done is really making this project look promising. The features look like they are being implemented in a good sensible fashion. I hope it continues that way and becomes a popular choice.
Yes, I agree. When it first came out, interestingly enough, there were many nay-sayers, yet, judging from one of the better known ones and some personal correspondence, many are realizing that as the BSD's become more trendy, for lack of a better word, it was inevitable.
vBulletin® v3.8.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.