New to the BSD world

DutchDaemon said:
OSS 4 is in ports (audio/oss)
Code:
PORTNAME=       oss
DISTVERSION=    4.2-build2000

Well then like I said that list was a small one hehe, stratch oss off the list then, thanks dutch. That just leaves the 2 most important ones (To me anyways) wine 1.1.29 (working under amd64) and nvidia-drivers for amd64 (which as mentioned i might get those under the Christmas tree this year)

im guessing that XFCE doesnt work so hot under bsd? I couldnt get him resuscitated. Maybe kde will work better. I dont expect bsd to tie my shoes, but I couldnt find what lone dingleberry was keeping xfce from starting (I tried 3 different commands listed in the handbook and on the forums and I followed the instructions for making the xinitrc or whatever)
 
I've had zero troubles with XFCE4 under FreeBSD 7 and 8; it's fast and uses little resources. I just use startx with .xinitrc (startxfce4) though, don't care for login managers.
 
this thread is going on a bit, but...

as they say:
linux is a child of the internet

but BSD is the mother of the internet.
BIND = Berkely Internet Name Daemon
TCP, sockets all grew up on BSD.
Read the Stevens' books, APIUE and UNP and it's peppered with
this protocol and that system call "first appeared on BSD blah.blah".

but this chap can put it better:

the greatest software ever written
 
nerdistmonk said:
im guessing that XFCE doesnt work so hot under bsd?
Xfce works fine. And it can work on 10-years old H/W. I don't use DMs either, but when I tried XDM with Xfce, it worked exactly like it should, from the first time.
Before trying to start Xfce, did you make sure *Xorg* was working fine?
 
Hrm, I have KDE4, XFCE4 and WindowMaker working on -STABLE fairly well in the same machine, all added through packages. There are well documented ways to add up DE's and setting up startx or a login manager.

From my experience, users coming from linux need to set aside for a lil' bit their working linux knowledge and follow the handbook until they understand the way FreeBSD intends to work, becasue the linux learning curve gets in the way at the very beggining. Once you acknowledge that, you can add up your linux learning curve to the mix.

Edit: damn typos!
 
nerdistmonk said:
3)Wine working as good as it does under the linux (1.1.29 works as good as having windows IM SERIOUS)

About that point, truth is wine has made giant steps, but a full 8 years (in a few days) of XP uninterrupted stable realm really helped. This means vendors keep producing win32 code for drivers and software. This particular condition has worked to wine's benefit, particularly within linux since its custom built considering it first before BSD or Solaris. That's why you have working binary blob drivers for funky webcams in linux, for example.


But windows 7 introduces a very different set of rules. Windows 8 in a couple of years might break all backward compatibility and relegate to virtualization (not emulation). Microsoft wants computers to be renewed each 3 or 4 years to keep taxing the user. Once oldschool win32 support phases out in the gaming industry, then it will be uphill once again for games, wine, and binary blobs.

FreeBSD doesn't have, for example, many of those benefits, but won't have to regret later for broken compatibility. Just keeping it real. I'm glad ubuntu+wine, for example, solves many small business problems related to (legacy or not) software, and the power gamer can do with a linux box, but are you really wishing to keep embracing old win32 binaries (or early win64 which has the same curses) and their coding practices altogether in order to maintain the status quo?

The linux gamer power user is very biased to keep embracing windows-only tech and complaints when it's unavailable, which is very ironic. I would thought that instead the gamer with extra requirement would be learning the powershell and tweaking windows services for unix, or have a working "windows server" workstation instead. Using the right tool for the right job doesn't necessarily mean it would be for free (be it in $ or time learning)

I admit, as I said, using the right tool for the job, even if its Windows, if otherwise you wouldn't be able to (like gaming) because of the mainstream dictates so, but you're losing the big picture here.

FreeBSD, and ultimately linux as well, is out of most the mainstream picture because of unsupported hardware and software from the vendor's part (binary blobbing is a big issue), not because the systems themselves are unusable.
 
aragon said:
And the new OSS in 8.0 is possibly better than OSS v4...

I replaced my Soundblaster XFI (Dont hurt me :) ) and put a soundblaster 4670 in, so bsd will love me for that.

and I dont need wine to run Windows 7 programs, every game I own (about 500 games) is designed for XP and 1.1.29 will run most of them (I cant play them all, not enough time) so I could care less about further updates, if freebsd gets 1.1.29 working under amd64 then im golden, almost all other issues are fixing themselves through the course of time.
 
I'm not sure how well it works, but there are instructions for compiling wine on freebsd amd64 here. It might be worth a shot. I was planning to test it out myself when I switch to amd64 with 8-Release.
 
foo_daemon said:
I'm not sure how well it works, but there are instructions for compiling wine on freebsd amd64 here. It might be worth a shot. I was planning to test it out myself when I switch to amd64 with 8-Release.

wow well that should be very hard I wonder if that can be applied to amd64, also did I mention that while im not neccsarly scared of the command line, I am by no means a terminal god?
Ill try this thats if I find 1.1.29 (not that I have the hots for build numbers, but that one has been very nice to me game-wise) so hopefully something good happens thanks foo.

(Believe me, when ever I sit down in front a pc, it isnt like you hear trumpets with the ground a shaking and a catholic choir singing ROFL)
 
Back
Top