Ok, I regret calling you a troll - made a mistake, thought you wrote the grandparent post. That said, I didn't speak about the superiourity of one OS over another - and no, I don't think init scripts are the most important factors in evaluating an os. And FreeBSD isn't my pet OS - it just suits most of my needs, and that's it. When it doesn't, I use WindowsXP (installed it on my gf's laptot, for she uses SPSS, I have it on my on puter as well, along with Slackware 10). Nevertheless, I do think that what you wrote is innacurate at best - there is far less to worry about in the rcNG world of Free/NetBSD than in SysV Init, and your insistence on the issue without addressing any of the points I made, even though I gave specific examples made me think you're trolling.
My only point about rc.conf in FreeBSD is that not all services are controlled there, one does have to be familiar with what's set up on the machine.
You see? Example? I don't run every service there is, so I can be wrong (mysql/apache, sshd, pureftpd on one server, samba on another, plus all on my home/test machine) - but I have yet to find a sercice that is not controlled by rc.conf. "One does have to be familiar with what's set up on the machine" - Thank you Mister Stating_the_Obvious - isn't that true for any important production system? Tell me you don't have to know what's installed on your linux server to run them properly.
How do you know which file you have to swap out? How can you say that searching for a specific file (how do I know its name - or rather, why do I have to know its name?) and "swapping" it out is easier than inserting a hash mark before samba_enable="YES"
Your laughter rings quite hollow btw. Can you explain the joke? How are runlevels better with having to edit a separate file just to have a graphical terminal?
---snip--- ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/local/bin/kdm" unknown off secure</a>
It is because turning that off to on is more simple or what? It doesn't matter really though, you proved multiple times that you don't know what you're talking about. In fact I'm pretty sure that you're really trolling. There is one ports system for all the bsd releases btw. (in answer to your other comment) Is there an event when a port doesn't work? Sure - out of 12000+ ports of 3rd party software, yes, there are some that might be temporarily broken. Just like in any other OS I have tried that supports lots of 3rd party software.
The way you sidestep the issues I rised (rcNG vs SysV Init - tell me how the the latter is superiour - does it have proper dependency checking, or the order is decided by the name of the files lol) and bring in new ones is just pathetic. Have a nice day.
It's running on my work and home desktop and my laptop. It runs KDE and GNOME, with all the bells and whistles, with absolutely no problems.
And what did you have to do to achieve this? What did you have to compile?
Well, I don't think grandparent was a troll, but it was (is still) -5 uninformed. What you have to do to run kde is install it from the first CD (takes 5 minutes). Or, you can: pkg_add -r kde. AND you have a choice to install it from ports, compiling it for your specific hardware with optimizations. All it takes is one command: portinstall kde - if you want everything but the kitchen sync, or if you want a streamlined kde: portinstall kde-light.
4. rc scripts actually a little more complicated in FreeBSD, they're in more places, but less than half hour to learn. boot process of FreeBSD is weird too. Package and ports are trickier for sure in FreeBSD
What?! One of the best things in FreeBSD is that startup scripts are much less complicated than in linux. Startup scripts for services included in the base system:/etc/rc.d Startup scripts for packages installed from ports:/usr/local/etc/rc.d - And that's it about it. And you don't even have to no anything about startup scripts. When you install a package, it installs a startup script in rc.d, and you only have to know one thing about startup scripts to have it enabled: put one single line in rc.conf. Just to make it sure that no one thinks that FreeBSD is complicated - this is my entire rc.conf, which controls almost all aspects of the system:
# pf options pf_enable="YES" pf_rules="/etc/pf.conf" # rules definition file for pf pflog_enable="YES" # start pflogd(8) pflog_logfile="/var/log/fw/pflog" # where pflogd should store the logfile
That's the best thing about bsd's rc system: you don't have zillions of symlinks in various runlevel directories. You don't have to worry about proper naming either. rcNG (NG=next generation) checks for dependencies automagically: you instal samba, put samba_enable="YES" in your rc.conf - end of your worries, for all the services it needs will be started up automatically.
The only reason for thinking it's complicated is that it is simple:) - as weird as it may sound. When I switched from linux, (of course I read the handbook) sometimes I had this feeling that there must be something more to it I am not aware of. And I thought that because I can't find it, it must be more complicated, until I realized that it is really that simple. No/etc/sys/networking/somefile (mandrake) or/etc/networking (debian) just to config your network interfaces. See my rc.conf - that's the simplicity and user-friendliness of BSD.
About yum - please, don't suggest such things. In FreeBSD, the best thing is that you don't have to worry about dependencies and about adding some package repositories (than removing others, because they conflict with each other). The ports system just works, without any need to configure it (except one line which is like "CHANGE_THIS.freebsd.org" preceded by a comment to put there your local mirror - but only if you installed the portupgrade tools). No freaking repositories (just over 12000 ports - see freshports.org)
Yeah, at least a bi-montlhly status report would be great, although this one is pretty huge and a very interesting read. My random favorite parts: (for those who find the report too long to read)
Thanks to Michael Johnson, the FreeBSD GNOME team has recently been given permission to use the Firefox and Thunderbird names , official icons, and to produce officially branded builds. Mozilla has also been very interested in merging our local patches back into the official source tree. This should greatly improve the quality of Firefox and Thunderbird on FreeBSD moving forward.
Nice to see that there is good cooperation between FreeBSD and the Mozilla Project.
FreeBSD profile.sh
URL: https://projects.fsck.ch/profile
Contact: Tobias Roth <ports@fsck.ch>
FreeBSD profile.sh is targeted at laptops. It allows to define multiple network environments (eg, home, work), and will then detect in which environment the laptop is started and configure it accordingly. Almost everything from under/etc can be configured per environment, and only the overrides to the default/etc have to be defined. Suspending in one environment and resuming in a different one is also supported.
Proper integration into the acpi/apm and several small improvements are underway. More testing with different system configurations is needed.
That's a nice touch for laptop users, and I never heard about it, though I follow some of the mailing lists pretty closely (but than, I just learned a week ago that I don't have to go through the shutdown-p now routine to switch off my puter - pressing the power button will will suffice).
FreeBSD 5.3 is the first release to include PF. It went out okay, but some bugs were discovered too late to make it on the CD. It is recommend to update `src/sys/contrib/pf' to RELENG_5. The specific issues addressed are:
* Possible NULL-deref with user/group rules. * Crash with binat on dynamic interfaces. * Silent dropping of IPv6 packets with option headers. * Endless loops with `static-port' rules.
Most of these issues were discovered by FreeBSD users and got fed back to OpenBSD. This is a prime example of open source at work.
PF rocks! I just swithed to pf from ipfw2, and even though ipfw is really good and easy to configure compared to iptables/ipchains, pf is even more noob friendly. You can do powerful things with pf _very_ easily.
Some other things: PHK's status report is in itself very interesting. So are the more gory details of changes in the OS internals. It seems to be that there is a general trend of modularizing the system and providing good API's for 3rd party development (GEOM comes to mind). Also: what's not in the status reports - the recent kickoff of freebsd-usb mailing lists that tries to enhanche ehci (usb2). There was a recent call to arms for rewriting the FreeBSD sound system. Many improvements in the bktr (tvtuner) driver over the past few months. Jeff's schedgraph that measures scheduler performance, and only two days after commit there were some bugs fixed in the scheduler that increased performance by 10%.
Although 5.3 was a good release (worked like a champ on my server and my desktop machine) - I'm very much looking forwards to 5.4. I upgraded all my puters to 5-STABLE, and they seem to run fine, and, I already see a slight performance increase (it can be just the driver upgrades, my server has the problematic if_sk). If they can fix ULE for 5.4 (or at least unbreak it) than FreeBSD would be a very good desktop choice as well (not that it isn't currently - it is somewhat more responsive than 2.4.x based linux distroes, but it isn't as good as 2.6.x, not with the 4BSD scheduler).
Not only that but this is what Mike Prettejohn (of Netcraft) wrote when asked about FreeBSD:
Initially [early 1995], we opted for FreeBSD because it was similar to SunOS, which we knew and liked.
We felt safer with FreeBSD because we were quite conscious of the security implications of the Internet. We wanted to run an operating system for which source was available in the expectation that fixes for security vulnerabilities or other serious bugs would become available more quickly, and if needed we would have the opportunity to write it ourselves.
FreeBSD wasn't a big investment in money or time, and so we thought if we wanted to replace it when something better came along it wouldn't have cost us much.
So far [nine years & counting...] we've not felt the urge to replace it:)
Re:I will resume my opinion of Xfce in three words
on
Xfce 4.2.0 Released
·
· Score: 1
Hey, flux can look great if you spend the time to set it up properly. On the other hand, I'm really impressed with the XFCE screenshots. I used XFCE a year or so ago - now I'm using KDE on stronger machines, and fluxbox/rox on lower-end machines. Didn't like the filemanager back then - did it improve? There is still rox if didn't though...
I know you're joking, but just for clarity's sake: the BSD licence does allow to put another label on your beer, but it doesn't allow you to claim it is your own.
Basically, the BSD licence is similar to PHK's (another FreeBSD developer) Beer-Ware Licence
* "THE BEER-WARE LICENSE" (Revision 42): * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
Both projects need to exist because of who we are.
Well, that's my point, you only managed to put it in one sentence instead of my clumsy and somewhat hasty (and by now I admit it) arrogant comment. What is clear from the so many flames I read that there is no way to create a desktop that a hardcore gnome user and a hardcore kde user will be comfortable with. Probably the way I set up kde would be a nightmare for a gnome user:) Furthermore, there is always a choice for a distro maker to customize the defaults, even for distroes that ship vanilla kde. In FreeBSD I can install the kde metaport (that includes everything and the kitchen synk) or kde-light which is basically kdelibs, kdebase and qt. If one chooses the latter,the KDEmenu (and other menus) are hardly cluttered. Nor would I find all the goodies I became to like (various service menus, additional menu entries in konqi menus, etc.).
Anyway, the article is good enough and can stand on it's own without the unfortunate metaphor it begins with.
Well, you're right, the article is not bad at all (nor are the others). My point is neatly underlined by the post above yours ( theantix ) - we have a good number of users repeating this over and over, and now we have this stereotype encoured from semi-official sources. I think that "cluttered" is somewhat pejorative compared to "feature rich" for instance.
I'm no longer that much of a partisan either (well, sometimes the 'old fire' - hehe - still shows through, as you can see from my post above) - and I find myself using fluxbox-devel more and more (with a number of gtk apps).
[RANT=ON]
You read the title of my comment:) Now a disclaimer: I'm not a GNOME user. And usually I don't post in GNOME related news b/c most of the time I don't read it. Now I did, and something strikes me as curious.
We all know of the KDE vs GNOME debate. There can't be a KDE announcment posted on OSNEWS without GNOME-fans spamming the thread with "konqueror is sooo cluttered I can't use it" kinda messages. Well, that's why you use GNOME, don't you, so why do you want KDE to be like GNOME if you already have something that satisfies you, and we, KDE users have something that satisfies us. That's what I usually think. I don't know about GNOME announcments for I don't read them. Maybe KDE users - well, lets call them for what they are: zealots - spam GNOME announments as well, I don't know. I don't say a KDE guy shouldn't comment in GNOME threads, or vice versa - it's just beating the same horse over and over again is not quite useful. WE LIKE FEATURES, and I don't feel like I can't use Konqi because there are 4 extra buttons on its toolbar compared to firefox.
Anyway, what prompted me to comment on this is that I thought that this is only a small but vocal minority of the overall user-base of GNOME. Afterall, projects with a significantly large userbase will have its share of zealots. But the very first link I clicked in this announcement begins with this (well, the first comments after the quotes):
I would argue it was already an in accurate caricature when it was written, but was spot on only a year or two before. When I first read that page, on balance, I thought it made it sound better to be a GNOME developer than a KDE developer. At least GNOME developers sounded creative and lively.
Today, I would argue that the caricatures are almost reversed. GNOME is a paragon of usable, restrained, unimaginative, corporate development. KDE is lively, nimble, cluttered, and a little crazy. What happened? How can we get the good aspects of "old GNOME" back without returning to diagramming in puddles of spilt beer, urine and vomit?
This is quite dissappointing. Why does the GNOME JOurnal have to begin with talking about KDE? Who writes GNOME journal? Is it "official"? Because this preoccupation with KDE, the irresistible urge to compare and judge (we the HIG people, they the Clutter people) the rival project is somewhat pathetic. Now I didn't read the rest of the articles - and I may be in the wrong here, but I find it sad that what ruins most of the discussions in KDE vs GNOME debates (because an interesting discussion _is_ possible I believe) is exactly the kind of crap we read in the opening lines of an (at least semi)official journal.
But then if I could get a hold of a copy of your copyrighted work, I could build the invention myself -- your copyright wouldn't stop me from doing that.
True. The difference between a world with ideas/software patentable and a patent-free world is only this: in the case of the former, your idea is already stolen before you even come up with it.
To put it differently: you come up with an idea you have no means to implement at the moment. Should you be granted a patent for your idea? Because if you should, than I have lots of ideas, which, if I had the means, I would patent asap. Are these great ideas? Maybe some of them... Do I have to prove that they are? (proof is in the pudding - or rather, the implementation!). I just have to wait until someone builds a gadget that is based on my ideas (more or less) and then... sue! Yes, that would be great.
Actually, as I said, I don't have the money to patent my ideas. But [insert_name_of_random_corporation_here] has. And what these usually do is that they patent ideas as fast as they can. It doesn't matter if these ideas are great or not. If you patent 1000 ideas each year (I use ideas here in a very broad sense) there is a good chance that at least a few of them would be great ideas. And because they are great ideas, it is very likely that someone else would think about it, who instead of using the patent system as a lottery (and spend his/her money in patenting the idea), would build the thing. And because someone, who didn't bother to try to implement it patented it first, this inventor (of not just great ideas) would find himself in the court room.
Of course, this is just an example - a little bit exaggerated (or is it? we have seen these things before) but still it shows quite nicely how easily a patent system could be abused. And it WILL be abused, because there is no way you can filter all the patents that are applied for in the patent office. Also, if you are so brilliant as to think up the idea of The SuperGadget - you will have to work to get it built/implemented. If you come up with an idea of something that there is no way you can implement, than you are not that brilliant.
what would you do if you had a GREAT idea for a REVOLUTIONARY gaadget
If my idea was so complex that it couldn't be immediately realized (in other words, if I only had a theory of something) I would write it down and would copyright it.
By the volunteers devoting their time to kernel hacking?
Oh please! There are ~100 paid hackers working on linux (just the kernel and closely related things) at any time now. Working on linux is no longer charity (well, more precisely: it isn't just charity). Now contrast that with the 2 or 3 (only one paid to work full time for 9 months) in FreeBSD, or [how many?] in OpenBSD. Than check kernel vulnerabilities in the past few years in either of these projects.
This article is an important eye-opener I think. We (yes, metoo) like to point at Windows and its horrible track record. But how many kernel vulerabilities have been detected in Windows Server 2003? How many in IIS 6? What about these reports?. I don't think linux needs apologies, especially not "its a volunteer project" kinda apologies, because projects with far fewer resources thrown at it can now manage a better security record. Why?
Right on target. I hate this infatuation with uptimes. Best practice is if it isn't even reported (on netcraft for instance). But anyway, a long uptime != stable system. Long uptime = lousy admins. Longest uptime = time between two kernel vulnerabilities. Seeing how there are a few each year, no uptime should ever reach 365 days.
What may give an indication (but just an indication, one shouldn't take this too seriously either) of server stability/performance is the reliability chart of Netcraft, not their uptime chart. Bragging about uptime (or even taking uptime very seriously) is like publicly admitting that you are a fool.
Bad news for everyone - except for some open source advocacy. Gives a nice opportunity to show how MS talks bullshit - when they talk about security. Did anyone notice the date when Microsoft was notified?
Provided and/or discovered by: 1) Discovered independently by: * http-equiv * Andreas Sandblad of Secunia Research (reported to Microsoft on 2004-10-13).
That's right, Microsoft "we take security very seriously" Corporation has known about this vulnerability for almost two months, yet they leaved it unpatched? Why?
# SMP OPTIONS: # # The apic device enables the use of the I/O APIC for interrupt delivery. # The apic device can be used in both UP and SMP kernels, but is required # for SMP kernels. Thus, the apic device is not strictly an SMP option, # but it is a prerequisite for SMP. # -------------snip-------------- # Mandatory: device apic # I/O apic
(3 Nov 2004) For FreeBSD/i386 and FreeBSD/amd64, SMP support in the GENERIC kernel has been disabled by default because the SMP kernel can degrade the performance on UP machines. A kernel configuration file SMP, which can be used to enable SMP support, has been added. More details on building the custom kernel can be found at http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/h andbook/kernelconfig.html.
SMP kernel does not cause lockups on UNI machines. You may be confusing ACPI lockups that troubled pre 5.3 releases (and in some cases 5.3 as well)? FreeBSD from 5.2 to 5.3 came with "options SMP" in GENERIC enabled. You say:
but that's how it is. at least it is when I move a p6-built kernel from my dual xeon box to my single k8 box. both DO accept p6 as the ARCH type but the SMP code just causes a lockup upon boot.
Are you sure it's the SMP code itself? As I said, 5.2/5.2.1 shipped with an SMP kernel by default, and I didn't see hang problems because of SMP (ACPI was a different issue). Also, someone mentioned APIC - which might be the case on some boards, but right now I run an APIC enabled non-smp kernel on my UP box (athlon xp 2400+, crappy asrock mb). I think it is more likely that code compiled on your dual xeon box won't run smoothly on your athlon64, smp or not, even though you might have specified i686 in your make.conf. (also, did your specify p6 with CPUTYPE?=i686)?
Also, it must be emphasised that these are microbenchmarks. Robert Watson explains nicely the situation:
Since the performance optimization on FreeBSD for the last few years, with features like SMPng, libpthread, and UMA, has been focussed on macro performance not micro performance, it's not surprising the micro performance requires tuning. However, there is lots of on-going work on this front so I'd expect to see continued improvement in the immediate (5.4) life time. There are a number of optimizations in 6.x that are on the merge path for 5.x that will directly impact the results in these measurements -- in particular, what is clearly a bug in the way mutexes are released on UP kernels that adds almost a hundred cycles to every mutex release operation. This was identified in my micro-benchmarking shortly after the release of 5.3, and may play a substantial part in the posted results, especially for the very micro benchmarks that involve kernel memory allocation.
It is also unfortunate, that the otherwise excellent benchmark, when mentioning the barrage of criticism leveled at freebsd (of which 90% is posted by random and anonymous trolls on both./ and osnews I might add) he refers to the "article" of this guy. This was my reply - and his adequate asnwers seems to be putting me on his foe list (lol.)
Anyway, I don't want' to downplay the importance of this benchmark (nor does rwatson, if you read the whole of his post) - in fact, I'd like to see more of these coming. And overall, it was a good reading:)
It's a pity that your first reference to the massive barrage of criticism FreeBSD received is to this guy's crappy journalism.
On the other hand: nice (micro)benchmarks! Thanks:) It appears that FreeBSD developers know of these issues:
Since the performance optimization on FreeBSD for the last few years, with
features like SMPng, libpthread, and UMA, has been focussed on macro
performance not micro performance, it's not surprising the micro
performance requires tuning. However, there is lots of on-going work on
this front so I'd expect to see continued improvement in the immediate
(5.4) life time. There are a number of optimizations in 6.x that are on
the merge path for 5.x that will directly impact the results in these
measurements -- in particular, what is clearly a bug in the way mutexes
are released on UP kernels that adds almost a hundred cycles to every
mutex release operation. This was identified in my micro-benchmarking
shortly after the release of 5.3, and may play a substantial part in the
posted results, especially for the very micro benchmarks that involve
kernel memory allocation.
You may find the the rest here. It is also a pity that some troll spammed every single FreeBSD mailing list with a "haha, freebsd developers suxorz, especiall PHK and DES" kinda message. Reminds you anyone we know?:))))
The licence FreeBSD had extended to JDK 1.3.x binary distribution only. If you wanted a higher version, you had to do what apparently OpenBSD users have to: download the sources manually and put them in/usr/ports/distfiles/ .
That's why the lawyers are winning right now. It's not because they're smarter. It's because they are SO good at twisting things around, and us geeks can't speak in public worth a damn.
Except perhaps swedish lawyers? Funniest quote from the article:
The Pirate Bay is a BitTorrent tracking site in Sweden with 150,000 users a day. In the fall, it posted a torrent for Shrek 2. Dreamworks sent a cease-and-desist letter demanding the site remove it. One of the site's pseudonymous owners, Anakata, replied: "As you may or may not be aware, Sweden is not a state in the United States of America. Sweden is a country in northern Europe [and] US law does not apply here. It is the opinion of us and our lawyers that you are fucking morons." Shrek 2 stayed up.
Now, my question is, can you tell the ports system not to use aRts globally, for any package? If not, then ports and portage are basically equal -- it's just a trade-off depending on how many exceptions you need to make.
Well, this is a difficult question. You see, almost all ports have built knobs, but not all of them save config in/var/db/ports/. Why? Because some of them, (like mplayer - and that answers your other question) autodetects whether a library is present or not. If you want explicitly to tell mplayer to bring in a new dependency, for instance, LiveMedia, you'll have to tell by passing WITH_LIVE=true to make. Since we are talking about new dependency, we don't have to worry about not saving this config, for after mplayer installs it because our WITH_LIVE=true flag, next time it will autedect it on our system, so support will be built in automatically.
Now it is possible to define a use flag for multiple ports. The first port most users install is portinstall/portupgrade. (It's not part of the base system b/c of its ruby dependency). You can install all your ports with portinstall. Let's say you want to install 30 ports on your weekend, and don't want any of them to use arts. What you do is: portinstall xmms mplayer totem audacity bla blah -x WITHOUT_XINE=true. The WITHOUT_XINE flag will be passed to all ports (it just won't be honored by those that don't know about xine).
But essentially, you will never have to do such configuration. QT will never be built unless you want it to, simply because if it's there,those apps that can support it optionally will support it automatically. If it's not there, its support won't be built. If you want support for it, than you define it (once). arts is a good example. (1) You don't want mplayer to build arts, because you'll never have arts on your puter. You don't have to do anything to achieve that. (2) You know you'll build kde later, and arts is part of kde, but you want to build mplayer now, and with arts support: you portinstall mplayer -x WITH_ARTS=true. This is a lot more easier than it sounds. Basically you don't have to configure anything to have a lean and mean system. There are only a few apps you want special tweaks for, but ports tell you about them. For instance, when you install mplayer, you are notified that there are a lot of options in the Makefile, and if you want to you can disrupt build now and check them. Snippet from makefile:
pre-everything:: @${ECHO_MSG} "N - O - T - E" @${ECHO_MSG} "" @${ECHO_MSG} "Take a careful look into the Makefile in order" @${ECHO_MSG} "to learn how to tune mplayer towards you personal preferences!" @${ECHO_MSG} "For example," @${ECHO_MSG} "make WITH_GTK1" @${ECHO_MSG} "builds MPlayer with GTK1-GUI support."
Now as you see (pre-everything), this will displayed before sources are downloaded and./configure begins. And if you check the makefile, you'll see that additional options are there right at the top and are very well commented. Why I think this is better is that (and that ansers your other question) for instance, for OpenOffice, there were only a few flags, one of which was WITH_TTF_BYTECODE_ENABLE=true - which you have to define manually because of apple patents. The reason for no options screen is that ncurses is really a simple interface. You can't have more there than a few checkboxes and a short description, not a detailed explanation of patent issues. But you know of this option just as you do in case of mplayer, because a message is displayed "pre-everything". Out of my 361 installed ports, there are only these two I had to hand-tweak. Now in gentoo land, you would have to have yet another use-flag you can put in your config file
Well, I would assume that a binary would come with all the optional functionality included, in order to work in the widest range of configurations.
I think this depends on the distro maker. Perhaps ubuntu is such a streamlined distro (I heard raves about it, though I'd never touch - I'm a KDE guy).
Now ufed (first I thought you missed the s) sounds like a very good idea. It would be nice to see a gui implementation. For instance, KDE could be represented as a dragon, and if you want nspluginscanner to work, you'll have to add a larger nose or something. Anyway, joke aside, it would be extremely hard to implement in a user friendly way, but still, the idea sounds interesting. Note that I didn't touch gentoo since may last year, so I'm a bit out of touch, and I might be wrong on several points. I hope next portage will be better (I want proper reverse dependency lookup implementation, not a world file).
Anyhow, I think use-flags is complex. Or rather, portage is complex, just like ports is complex in freebsd. My problem is that most of that complexity is dumped on the user in gentoo, while in fbsd, it largely rest on the shoulders of the port maintainers.
Now I don't mean to advertise my favorite OS: frankly I don't care whatever other folks use (Just so you know: I installed windows xp sp2 on my girlfriends laptop). This is just an example how it is done in ports.
Example: amarok. snippet from the makefile:
OPTIONS= ARTS "aRts support" off \ GSTREAMER "GStreamer support" on \ XINE "xine support" off \ XMMS "XMMS visualizations" on \ LIBVISUAL "libvisual support" on \ OPENGL "OpenGL support" on \ AMAZON "Amazon cover fetching support" on
Now you (as a user) don't have anything to do with that. When you first install amarok, you will see this. Then the options you choose will be saved to/var/db/ports/amarok/options, and it would look like this:
root@mcsaba# cat/var/db/ports/amarok/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for amarok-1.1.1_1 _OPTIONS_READ=amarok-1.1.1_1 WITH OUT_ARTS=true WITH_GSTREAMER=true WITHOUT_XINE=t rue WITH_XMMS=true WITH_LIBVISUAL=true WITH_OPE NGL=true WITH_AMAZON=true
As you can see, it's not very difficult to parse this file or write them with hands, but you don't even need that. Ports will be configured as you go installing them, and the only thing you have to know (instead of lots of useflags) that you can always check the Makefile for additional build knobs - which are very well commented by the way. (takes only a few seconds). You can instruct the ports system to build those ports first that need manual intervention, so you can have all the config files in place. Or, alternatively, you can instruct the portsystem to build only those ports that don't need manual intervention. And you can safely leave your puter to build for the weekend (even if some ports fails, only those package/ports won't be built that depend on them), and when you come back, you'll be presented with a list of those ports that got build, those that were ignore or failed (and the reason why they failed) in a nice summary.
Anyway, if a nice frontend can be written to use-flags, be it gui or text (or ncurses) based, that would solve this problem, and gentoo would have best of both worlds (less work for maintainers - not that writing those Makefiles is that difficult) and less work for the users, but the problem is: it is a very complex task, and it should still give the user a good idea of what will be the (missing or present) functionality of each software he or she installs (before he or she installs it tha
Slashdot Mirror
My only point about rc.conf in FreeBSD is that not all services are controlled there, one does have to be familiar with what's set up on the machine.
You see? Example? I don't run every service there is, so I can be wrong (mysql/apache, sshd, pureftpd on one server, samba on another, plus all on my home/test machine) - but I have yet to find a sercice that is not controlled by rc.conf. "One does have to be familiar with what's set up on the machine" - Thank you Mister Stating_the_Obvious - isn't that true for any important production system? Tell me you don't have to know what's installed on your linux server to run them properly.
Your laughter rings quite hollow btw. Can you explain the joke? How are runlevels better with having to edit a separate file just to have a graphical terminal?
It is because turning that off to on is more simple or what? It doesn't matter really though, you proved multiple times that you don't know what you're talking about. In fact I'm pretty sure that you're really trolling. There is one ports system for all the bsd releases btw. (in answer to your other comment) Is there an event when a port doesn't work? Sure - out of 12000+ ports of 3rd party software, yes, there are some that might be temporarily broken. Just like in any other OS I have tried that supports lots of 3rd party software.The way you sidestep the issues I rised (rcNG vs SysV Init - tell me how the the latter is superiour - does it have proper dependency checking, or the order is decided by the name of the files lol) and bring in new ones is just pathetic. Have a nice day.
Well, I don't think grandparent was a troll, but it was (is still) -5 uninformed. What you have to do to run kde is install it from the first CD (takes 5 minutes). Or, you can: pkg_add -r kde. AND you have a choice to install it from ports, compiling it for your specific hardware with optimizations. All it takes is one command: portinstall kde - if you want everything but the kitchen sync, or if you want a streamlined kde: portinstall kde-light.
learn more... it's not that difficult.
What?! One of the best things in FreeBSD is that startup scripts are much less complicated than in linux. Startup scripts for services included in the base system: /etc/rc.d Startup scripts for packages installed from ports: /usr/local/etc/rc.d - And that's it about it. And you don't even have to no anything about startup scripts. When you install a package, it installs a startup script in rc.d, and you only have to know one thing about startup scripts to have it enabled: put one single line in rc.conf. Just to make it sure that no one thinks that FreeBSD is complicated - this is my entire rc.conf, which controls almost all aspects of the system:
That's the best thing about bsd's rc system: you don't have zillions of symlinks in various runlevel directories. You don't have to worry about proper naming either. rcNG (NG=next generation) checks for dependencies automagically: you instal samba, put samba_enable="YES" in your rc.conf - end of your worries, for all the services it needs will be started up automatically.The only reason for thinking it's complicated is that it is simple :) - as weird as it may sound. When I switched from linux, (of course I read the handbook) sometimes I had this feeling that there must be something more to it I am not aware of. And I thought that because I can't find it, it must be more complicated, until I realized that it is really that simple. No /etc/sys/networking/somefile (mandrake) or /etc/networking (debian) just to config your network interfaces. See my rc.conf - that's the simplicity and user-friendliness of BSD.
About yum - please, don't suggest such things. In FreeBSD, the best thing is that you don't have to worry about dependencies and about adding some package repositories (than removing others, because they conflict with each other). The ports system just works, without any need to configure it (except one line which is like "CHANGE_THIS.freebsd.org" preceded by a comment to put there your local mirror - but only if you installed the portupgrade tools). No freaking repositories (just over 12000 ports - see freshports.org)
As to the desktop: some obligatory screenshots.
Some other things: PHK's status report is in itself very interesting. So are the more gory details of changes in the OS internals. It seems to be that there is a general trend of modularizing the system and providing good API's for 3rd party development (GEOM comes to mind). Also: what's not in the status reports - the recent kickoff of freebsd-usb mailing lists that tries to enhanche ehci (usb2). There was a recent call to arms for rewriting the FreeBSD sound system. Many improvements in the bktr (tvtuner) driver over the past few months. Jeff's schedgraph that measures scheduler performance, and only two days after commit there were some bugs fixed in the scheduler that increased performance by 10%.
Although 5.3 was a good release (worked like a champ on my server and my desktop machine) - I'm very much looking forwards to 5.4. I upgraded all my puters to 5-STABLE, and they seem to run fine, and, I already see a slight performance increase (it can be just the driver upgrades, my server has the problematic if_sk). If they can fix ULE for 5.4 (or at least unbreak it) than FreeBSD would be a very good desktop choice as well (not that it isn't currently - it is somewhat more responsive than 2.4.x based linux distroes, but it isn't as good as 2.6.x, not with the 4BSD scheduler).
Cheers to FreeBSD developers.
Hey, flux can look great if you spend the time to set it up properly. On the other hand, I'm really impressed with the XFCE screenshots. I used XFCE a year or so ago - now I'm using KDE on stronger machines, and fluxbox/rox on lower-end machines. Didn't like the filemanager back then - did it improve? There is still rox if didn't though...
Basically, the BSD licence is similar to PHK's (another FreeBSD developer) Beer-Ware Licence
I wonder how many have adopted this licenceps. Now this" is really funny! :)))))
Well, that's my point, you only managed to put it in one sentence instead of my clumsy and somewhat hasty (and by now I admit it) arrogant comment. What is clear from the so many flames I read that there is no way to create a desktop that a hardcore gnome user and a hardcore kde user will be comfortable with. Probably the way I set up kde would be a nightmare for a gnome user :) Furthermore, there is always a choice for a distro maker to customize the defaults, even for distroes that ship vanilla kde. In FreeBSD I can install the kde metaport (that includes everything and the kitchen synk) or kde-light which is basically kdelibs, kdebase and qt. If one chooses the latter,the KDEmenu (and other menus) are hardly cluttered. Nor would I find all the goodies I became to like (various service menus, additional menu entries in konqi menus, etc.).
Anyway, the article is good enough and can stand on it's own without the unfortunate metaphor it begins with.
Cheers.
I'm no longer that much of a partisan either (well, sometimes the 'old fire' - hehe - still shows through, as you can see from my post above) - and I find myself using fluxbox-devel more and more (with a number of gtk apps).
We all know of the KDE vs GNOME debate. There can't be a KDE announcment posted on OSNEWS without GNOME-fans spamming the thread with "konqueror is sooo cluttered I can't use it" kinda messages. Well, that's why you use GNOME, don't you, so why do you want KDE to be like GNOME if you already have something that satisfies you, and we, KDE users have something that satisfies us. That's what I usually think. I don't know about GNOME announcments for I don't read them. Maybe KDE users - well, lets call them for what they are: zealots - spam GNOME announments as well, I don't know. I don't say a KDE guy shouldn't comment in GNOME threads, or vice versa - it's just beating the same horse over and over again is not quite useful. WE LIKE FEATURES, and I don't feel like I can't use Konqi because there are 4 extra buttons on its toolbar compared to firefox.
Anyway, what prompted me to comment on this is that I thought that this is only a small but vocal minority of the overall user-base of GNOME. Afterall, projects with a significantly large userbase will have its share of zealots. But the very first link I clicked in this announcement begins with this (well, the first comments after the quotes):
This is quite dissappointing. Why does the GNOME JOurnal have to begin with talking about KDE? Who writes GNOME journal? Is it "official"? Because this preoccupation with KDE, the irresistible urge to compare and judge (we the HIG people, they the Clutter people) the rival project is somewhat pathetic. Now I didn't read the rest of the articles - and I may be in the wrong here, but I find it sad that what ruins most of the discussions in KDE vs GNOME debates (because an interesting discussion _is_ possible I believe) is exactly the kind of crap we read in the opening lines of an (at least semi)official journal.[RANT=OFF]
True. The difference between a world with ideas/software patentable and a patent-free world is only this: in the case of the former, your idea is already stolen before you even come up with it.
To put it differently: you come up with an idea you have no means to implement at the moment. Should you be granted a patent for your idea? Because if you should, than I have lots of ideas, which, if I had the means, I would patent asap. Are these great ideas? Maybe some of them... Do I have to prove that they are? (proof is in the pudding - or rather, the implementation!). I just have to wait until someone builds a gadget that is based on my ideas (more or less) and then... sue! Yes, that would be great.
Actually, as I said, I don't have the money to patent my ideas. But [insert_name_of_random_corporation_here] has. And what these usually do is that they patent ideas as fast as they can. It doesn't matter if these ideas are great or not. If you patent 1000 ideas each year (I use ideas here in a very broad sense) there is a good chance that at least a few of them would be great ideas. And because they are great ideas, it is very likely that someone else would think about it, who instead of using the patent system as a lottery (and spend his/her money in patenting the idea), would build the thing. And because someone, who didn't bother to try to implement it patented it first, this inventor (of not just great ideas) would find himself in the court room.
Of course, this is just an example - a little bit exaggerated (or is it? we have seen these things before) but still it shows quite nicely how easily a patent system could be abused. And it WILL be abused, because there is no way you can filter all the patents that are applied for in the patent office. Also, if you are so brilliant as to think up the idea of The SuperGadget - you will have to work to get it built/implemented. If you come up with an idea of something that there is no way you can implement, than you are not that brilliant.
If my idea was so complex that it couldn't be immediately realized (in other words, if I only had a theory of something) I would write it down and would copyright it.
Oh please! There are ~100 paid hackers working on linux (just the kernel and closely related things) at any time now. Working on linux is no longer charity (well, more precisely: it isn't just charity). Now contrast that with the 2 or 3 (only one paid to work full time for 9 months) in FreeBSD, or [how many?] in OpenBSD. Than check kernel vulnerabilities in the past few years in either of these projects.
This article is an important eye-opener I think. We (yes, metoo) like to point at Windows and its horrible track record. But how many kernel vulerabilities have been detected in Windows Server 2003? How many in IIS 6? What about these reports?. I don't think linux needs apologies, especially not "its a volunteer project" kinda apologies, because projects with far fewer resources thrown at it can now manage a better security record. Why?
What may give an indication (but just an indication, one shouldn't take this too seriously either) of server stability/performance is the reliability chart of Netcraft, not their uptime chart. Bragging about uptime (or even taking uptime very seriously) is like publicly admitting that you are a fool.
That's right, Microsoft "we take security very seriously" Corporation has known about this vulnerability for almost two months, yet they leaved it unpatched? Why?
Says the submitter about his own article :)) Shameless Narcissism!
Options are still there, see /usr/src/sys/conf/NOTES:
And inbut that's how it is. at least it is when I move a p6-built kernel from my dual xeon box to my single k8 box. both DO accept p6 as the ARCH type but the SMP code just causes a lockup upon boot.
Are you sure it's the SMP code itself? As I said, 5.2/5.2.1 shipped with an SMP kernel by default, and I didn't see hang problems because of SMP (ACPI was a different issue). Also, someone mentioned APIC - which might be the case on some boards, but right now I run an APIC enabled non-smp kernel on my UP box (athlon xp 2400+, crappy asrock mb). I think it is more likely that code compiled on your dual xeon box won't run smoothly on your athlon64, smp or not, even though you might have specified i686 in your make.conf. (also, did your specify p6 with CPUTYPE?=i686)?
It is also unfortunate, that the otherwise excellent benchmark, when mentioning the barrage of criticism leveled at freebsd (of which 90% is posted by random and anonymous trolls on both ./ and osnews I might add) he refers to the "article" of this guy. This was my reply - and his adequate asnwers seems to be putting me on his foe list (lol.)
Anyway, I don't want' to downplay the importance of this benchmark (nor does rwatson, if you read the whole of his post) - in fact, I'd like to see more of these coming. And overall, it was a good reading :)
On the other hand: nice (micro)benchmarks! Thanks :) It appears that FreeBSD developers know of these issues:
You may find the the rest here. It is also a pity that some troll spammed every single FreeBSD mailing list with a "haha, freebsd developers suxorz, especiall PHK and DES" kinda message. Reminds you anyone we know?The licence FreeBSD had extended to JDK 1.3.x binary distribution only. If you wanted a higher version, you had to do what apparently OpenBSD users have to: download the sources manually and put them in /usr/ports/distfiles/ .
Except perhaps swedish lawyers? Funniest quote from the article:
The Pirate Bay is a BitTorrent tracking site in Sweden with 150,000 users a day. In the fall, it posted a torrent for Shrek 2. Dreamworks sent a cease-and-desist letter demanding the site remove it. One of the site's pseudonymous owners, Anakata, replied: "As you may or may not be aware, Sweden is not a state in the United States of America. Sweden is a country in northern Europe [and] US law does not apply here. It is the opinion of us and our lawyers that you are fucking morons." Shrek 2 stayed up.
Well, this is a difficult question. You see, almost all ports have built knobs, but not all of them save config in /var/db/ports/. Why? Because some of them, (like mplayer - and that answers your other question) autodetects whether a library is present or not. If you want explicitly to tell mplayer to bring in a new dependency, for instance, LiveMedia, you'll have to tell by passing WITH_LIVE=true to make. Since we are talking about new dependency, we don't have to worry about not saving this config, for after mplayer installs it because our WITH_LIVE=true flag, next time it will autedect it on our system, so support will be built in automatically.
Now it is possible to define a use flag for multiple ports. The first port most users install is portinstall/portupgrade. (It's not part of the base system b/c of its ruby dependency). You can install all your ports with portinstall. Let's say you want to install 30 ports on your weekend, and don't want any of them to use arts. What you do is: portinstall xmms mplayer totem audacity bla blah -x WITHOUT_XINE=true. The WITHOUT_XINE flag will be passed to all ports (it just won't be honored by those that don't know about xine).
But essentially, you will never have to do such configuration. QT will never be built unless you want it to, simply because if it's there,those apps that can support it optionally will support it automatically. If it's not there, its support won't be built. If you want support for it, than you define it (once). arts is a good example. (1) You don't want mplayer to build arts, because you'll never have arts on your puter. You don't have to do anything to achieve that. (2) You know you'll build kde later, and arts is part of kde, but you want to build mplayer now, and with arts support: you portinstall mplayer -x WITH_ARTS=true. This is a lot more easier than it sounds. Basically you don't have to configure anything to have a lean and mean system. There are only a few apps you want special tweaks for, but ports tell you about them. For instance, when you install mplayer, you are notified that there are a lot of options in the Makefile, and if you want to you can disrupt build now and check them. Snippet from makefile:
Now as you see (pre-everything), this will displayed before sources are downloaded and ./configure begins. And if you check the makefile, you'll see that additional options are there right at the top and are very well commented. Why I think this is better is that (and that ansers your other question) for instance, for OpenOffice, there were only a few flags, one of which was WITH_TTF_BYTECODE_ENABLE=true - which you have to define manually because of apple patents. The reason for no options screen is that ncurses is really a simple interface. You can't have more there than a few checkboxes and a short description, not a detailed explanation of patent issues. But you know of this option just as you do in case of mplayer, because a message is displayed "pre-everything". Out of my 361 installed ports, there are only these two I had to hand-tweak. Now in gentoo land, you would have to have yet another use-flag you can put in your config file
Well, I would assume that a binary would come with all the optional functionality included, in order to work in the widest range of configurations. I think this depends on the distro maker. Perhaps ubuntu is such a streamlined distro (I heard raves about it, though I'd never touch - I'm a KDE guy).
Now ufed (first I thought you missed the s) sounds like a very good idea. It would be nice to see a gui implementation. For instance, KDE could be represented as a dragon, and if you want nspluginscanner to work, you'll have to add a larger nose or something. Anyway, joke aside, it would be extremely hard to implement in a user friendly way, but still, the idea sounds interesting. Note that I didn't touch gentoo since may last year, so I'm a bit out of touch, and I might be wrong on several points. I hope next portage will be better (I want proper reverse dependency lookup implementation, not a world file).
Anyhow, I think use-flags is complex. Or rather, portage is complex, just like ports is complex in freebsd. My problem is that most of that complexity is dumped on the user in gentoo, while in fbsd, it largely rest on the shoulders of the port maintainers.
Now I don't mean to advertise my favorite OS: frankly I don't care whatever other folks use (Just so you know: I installed windows xp sp2 on my girlfriends laptop). This is just an example how it is done in ports.
Example: amarok. snippet from the makefile:
Now you (as a user) don't have anything to do with that. When you first install amarok, you will see this. Then the options you choose will be saved to /var/db/ports/amarok/options, and it would look like this:
As you can see, it's not very difficult to parse this file or write them with hands, but you don't even need that. Ports will be configured as you go installing them, and the only thing you have to know (instead of lots of useflags) that you can always check the Makefile for additional build knobs - which are very well commented by the way. (takes only a few seconds). You can instruct the ports system to build those ports first that need manual intervention, so you can have all the config files in place. Or, alternatively, you can instruct the portsystem to build only those ports that don't need manual intervention. And you can safely leave your puter to build for the weekend (even if some ports fails, only those package/ports won't be built that depend on them), and when you come back, you'll be presented with a list of those ports that got build, those that were ignore or failed (and the reason why they failed) in a nice summary.
Anyway, if a nice frontend can be written to use-flags, be it gui or text (or ncurses) based, that would solve this problem, and gentoo would have best of both worlds (less work for maintainers - not that writing those Makefiles is that difficult) and less work for the users, but the problem is: it is a very complex task, and it should still give the user a good idea of what will be the (missing or present) functionality of each software he or she installs (before he or she installs it tha