Slashdot Mirror
PC-BSD: The Most Beginner Friendly OS
soniyea writes "OSWeekly.com reviews PC-BSD and considers it the most beginner friendly OS in the market. 'From PC-BSD's roadmap to their default installation, I honestly feel good about where these guys are headed with their take on FreeBSD. This operating system has it all: support both from the professional level as well as that of the community, the ability to install Linux software, thanks to the binary compatibility layer, and of course — speed. Understand for most people, the speed factor is more or less a matter of opinion. But I have found that in some areas, it felt faster at the core level. Maybe I just had too much coffee that day? Either way, I totally recommend PC-BSD for anyone wanting to take a step into the wild side. FreeBSD, it's not just for geeks anymore.'"
The article is of very poor quality. It doesn't even provide a link to the PC-BSD website.
... when you plug in your scanner, printer, digital camera, mobile phone, PDA, dvcam .. and it just works. When you don't need to even figure what program would possibly deal with such devices to start with.
Maybe they should do a test... 20 beginners with no computer experience or familiarity, that would use this operating system, and e.g. Mac OS X, plain installed FreeBSD and XP, and see what they think is really the easiest to use. The beginners would be way better to tell this than someone who makes their living writing computer related articles.
The 6502's "zero page" instructions were a timesaver. Most instructions had a "shorthand" form which accessed a byte in the address space $0000-$00FF, using only one byte for the operand address, so saving a clock cycle and a byte of RAM. You could use zero page memory as an extended register set. If you were very clever, you could pull stunts with mapping different 256-byte chunks of memory into that space. Or you could use those addresses for faster-than-usual I/O {like the Atari 2600}. {The 6502 did not have separate I/O and memory buses.}
The BBC microcomputer used the 6502 {actually the 65C102 in its later incarnations} and that had an absolutely amazing BASIC. Even ran faster than some rival computers' machine code {thanks mostly to the use of hardware rather than software to generate the bitmapped display, which required up to 20KB of the 32KB for the framebuffer}.
The 6502, and the way the BBC used it, was also the inspiration for the ARM processor. SWIs were based on the BBC's MOS {kind of a BIOS on steroids; a full abstraction layer}. Basically, in order to access the BBC's hardware, you would set up a parameter block in memory; load its address into the X and Y registers and an instruction code into the accumulator; and call a fixed address in ROM {which pointed to an indirect jump instruction deriving its address from RAM, allowing user code to intercept MOS calls if necessary. You could have hours of fun with this}. If you only needed to pass two bytes and an instruction code then you could use the X and Y registers and call a different address. {I know, nowadays we pass parameters on the stack. This was the 1980s. Also, the 6502's hardware stack can only ever be 256 bytes big due to the S register -- the stack pointer -- being only 8 bits wide.} The whole display subsystem {including text, graphics, user-defined characters, display windows and colour/palette selection} was controlled by non-printable characters {and the graphics display was organised as 1280x1024, even though in real life it was only 160/320/640x256}. There was, of course, a MOS call to print a character. Every other piece of hardware -- the sound system, the keyboard, the printer, the serial port, the A-to-D converter, the cassette and disc file systems -- could be accessed through MOS calls. You didn't have to touch the hardware directly at all; in fact, as long as you didn't, the same programs {in BASIC or machine code} would work without modification on a plain Model B, a B with a 6502 second processor, a Master Series or a RISC-based machine with 6502 emulation. BBC BASIC was merely a layer on top of the MOS. For instance, the Beeb's sound chip had a programmable envelope generator controlled by 14 parameters. There was a MOS call which took a block of 14 parameters and loaded these into the sound chip's registers. The ENVELOPE statement in BASIC took 14 parameters, and merely made the MOS call for you.
Je fume. Tu fumes. Nous fûmes!
i tried it, PCBSD makes a decent KDE desktop, i noticed KDE's kooka was broken - i am guessing it was broken because sane was not installed, i did a little google search and noticed FBSD considers sane/xsane a vulnerability because the temp files it creates while running can be exployted, and when i tried to compile sane-backends it complained about no USB , so i get libusb and compiled it and still sane-backends complained about nousb, i did not bother with libgphoto2 since sane was not wanting to work, other than this minor annoyence PCBSD is a decent KDE desktop, it just needs to shed some of the FreeBSD strict access control (server security?) to make better headway in the desktop/workstation arena. as a faithful Linux user i am glad to see PCBSD as an alternative, and i see MidnightBSD is a BSD desktop too...
:)
BSD = i am not dead
Politics is Treachery, Religion is Brainwashing
Yes, there is. http://ezine.daemonnews.org/200302/fbsdscratch.htm l
o ks/handbook/
/etc/sysctl.conf.
/etc/make.conf which will compile everything with -march=athlon-mp), especially if you use Firefox or you may end up rather frustrated. OpenOffice now works perfectly on amd64, as does JDK15 (albeit without the browser plugin) but native Firefox still has "issues" (startup hangs on a machine with an NFS mounted /home, hard locks, crashes to name but a few problems I have encountered) and plugins are rather flaky. I tend to use the 32bit Linux version on amd64, but the native i386 version has the most plugins available for it (win32codecs, Flash - you need a patch to make Flash7 work with the linuxpluginwrapper and native Firefox, see the message displayed when you install the port - et al). Also, there are no proprietary nVidia drivers for amd64 yet, which is not true for i386. This is being addressed in -CURRENT as nVidia have intimated that a key function they require is not present in the amd64 port and the devs are working on it, so the situation is set to change in the near future.
First and foremost, read the handbook. This cannot be overstated. http://www1.uk.freebsd.org/doc/en_US.ISO8859-1/bo
Bear in mind that, for a Linux user, FreeBSD will appear to behave most like Gentoo, particularly when building applications from ports. The actual inheritance was the other way around, but that hardly matters to this discussion.
The kernel config file is flat text, with the various options described in detail in the ${SRC}/sys/conf/NOTES and ${SRC}/sys/${ARCH}/NOTES files. Once you get used to it, nothing ever comes close to the ease of compiling new kernels IMHO. Just watch what depends on what, especially the COMPAT_??? options. Also, try not to use "custom" compiler flags like -ffast-math and -funroll-loops as you can end up with hard to diagnose problems when building from source.
Oh, and for anyone reading this thread who is saying "I only have one dsp device that gets locked and nothing else can use it," there is a sysctl knob which needs setting: hw.snd.pcm?.vchans which I usually set to 4 in
There's a lot of help to be had on the Usenet group comp.unix.bsd.freebsd.misc, too.
My last word on the subject is this: If you have an amd64 machine, for now I would use the i386 port (CPUTYPE=athlon64 in
By the way, ports count at present is ~15500. That's 15.5 thousand services, applications, libraries and utilities available for the cost of typing "make install clean".
Resistance is futile. Reactance buggers it up.
Indeed. I wouldn't expect it to be such a draw now, but it is just a concrete example of the attention to detail of the BSD teams.
I can see how a more unified system would appeal to most people. It was never something that particularly bugged me, since I guess I'm still in the mindset of seeing a collection of utilities as opposed to a unified system
For the most part, it's little things. A good example is network configuration. On OpenBSD, everything to do with configuring network interfaces is done through ifconfig. On Linux (and, sadly, FreeBSD) you have a separate utility to control WiFi settings. One Linux user recently told me that ifconfig was now deprecated in favour of something else (I can't remember what) on Linux systems, although the man page makes no mention of this.
I might try installing a couple of the BSDs in virtual machines and at least giving them a fair go.
If you're running in a VM, I would suggest OpenBSD. I find the userland cleaner, and the lack of 3D support isn't going to be an issue in a VM. The install process can be a bit daunting; it's not actually that hard, but it doesn't do much by way of hand-holding so make sure you have the manual open.
Is there anything like "BSD From Scratch" that will tell you how to bootstrap a BSD install?
Not really. The concept isn't so important in the BSD world. A BSD is an operating system; a kernel and a basic userland (including compiler tool chain). Once you have installed *BSD, you have what is known as the base system. This is everything that is maintained by the BSD team (including a few third party utilities that have patch branches maintained by the team). This might include X, but won't include something like GNOME.
Once you have the base system installed, you then add ports or packages. On FreeBSD and OpenBSD, a port is a framework for building a third party application (including dependency resolution and applying OS-specific patches), while a package is the binary version of a port. You can create a package by running 'make package' in the port's directory. On FreeBSD, ports are the usual way of installing applications, and binary packages sometimes lag behind the ports (you can use them interchangeably, since a package is just a precompiled port; the portupgrade utility has an option to try installing the package if it exists, or to build the port if it doesn't). On OpenBSD, the pre-built packages are much more heavily tested than the ports (although they are only released every six months with a release of the base system and so are often slightly out-of-date) and are the recommended way of installing software.
If you really want to do something a bit more manually, there is a tutorial on Ping Wales about installing OpenBSD without using the OpenBSD installer. It's focussed on using an existing system to create a bootable flash image, but you can probably adapt it to a real system. I wouldn't recommend actually doing this, but you might find it informative.
The BSD community has a reputation for being slightly newbie-hostile. For the most part, this comes from two things:
I am TheRaven on Soylent News
Yes, they are but they also benefit from the CISC opcodes. I-Cache polution is a serious threat to inlining/unrolling and branch prediction.
With ARM style RISC opcodes operations heavy on memory [for example] are less dense than those of x86. e.g.
x86:
add eax,[ebx+ecx]
ARM: [map them to r0,r1,r2]
add r3,r1,r2 ; ebx + ecx
ldr r3,[r3] ; [ebx+ecx]
add r0,r0,r3
So the x86 world takes 3 bytes to do what ARM takes 12 [or 6 in THUMB mode]. Multiply this by a few hundred if not thousand for any given algorithm and you get the point.
Effectively the opcode decoders act like decompressors for x86 opcodes. Done on the fly for most opcodes. Of course in the case of AMD64 [and most likely the Core 2 stuff] most opcodes map to 1 or 2 RISC operations. The RISC engines are not as trivial as those in the ARM processor alone. So even if you scrapped the x86 side and exposed the internal engine it'd still be way cooler than ARM.
Tom
Someday, I'll have a real sig.
You do know that M$ used BSD-licenced code for their IP stack and Internet Explorer, don't you?
to the website. It looks like they have a windows like enviroment, but the real advantage is that they created an installer that doesn't rely on dependencies. Each application installs with all dependencies self contained, and with an installer that looks like a regular window/mac installer.
So it might be worth an install just to check out the system. Looks clean, they tout that it's fast, but I want to look for it myself. Will install this weekend on my Laptop and see if it really detects hardware like they say.
Skip the article, go to the website.
http://www.pcbsd.org/
Try the repaginator extension for Firefox
Soylent Green is peoplicious!
The best answer I found on this topic; it compares Debian, the best of Linux, to FreeBSD http://tinyurl.com/s74ws