Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BSD vs. Linux (2005)

over-yonder.net

Post reply on HN
Print view View original

341–350 of 371 posts

Re: BSD vs. Linux (2005)

#341

Post by throwaway7767 »

takeda wrote: post #267
siddhant wrote: post #56

Earlier quoted context omitted.

> you know where things are, and where they are supposed to be Does this not depend on the distro you're using?

It's more than what you see in Linux. For example in Linux you have system packages, packages that are in distro repo, and 3rd party repo all sorting configuration and startup scripts in /etc. In FreeBSD anything you find in /etc is part of the system, applications that you install are fully contained in /usr/local including etc and rc.d (init.d). /usr/local is also completely empty when you first install the system.

> It's more than what you see in Linux. For example in Linux you have system packages, packages that are in distro repo,

System packages are packages in the distro repo, so those are the same thing.

> and 3rd party repo all sorting configuration and startup scripts in /etc.

Stuff you compile/install from random sources on the internet will place its stuff wherever the upstream decided to place it. The same will happen if you compile that software on FreeBSD. If you're thinking of ports, those are patched to install to the usual places, exactly the same as the packages in the linux distribution repositories.

FreeBSD's base system is very neat and well-organised, and they have an impressive ports tree with ports that integrate fairly well for the most part. But that doesn't extend to third-party software, and it seems silly to include that in a comparison on the linux side.

Re: BSD vs. Linux (2005)

#342

Post by talideon »

caf wrote: post #329
talideon wrote: post #200

Earlier quoted context omitted.

> the "FreeBSD Desktop" is even more so. The funny thing is that there's a reason for that: up until recently, the focus of FreeBSD has been on being a server OS. There's a push recently on improving the graphics situation, but it's only relatively recent, and is mainly focussed on getting integrated graphics on more modern hardware working. There are also some efforts to expand the driver compatibility layer so that…

The containerisation approach on Linux isn't because of insularity or NIH - it's because the Linux kernel development process does not accept large, far-reaching "big bang" code drops. Instead, changes that have wide impact across the core kernel are expected to be made in a series of smaller incremental improvements, each of which is more limited in impact and more easily reviewed.

Why would borrowing the APIs enabling existing containerisation approaches have lead to large, far-reaching big bang code drops?

Re: BSD vs. Linux (2005)

#343

Post by knorker »

milcron wrote: post #314
knorker wrote: post #123

Earlier quoted context omitted.

> In this day and age not having proper dependency resolution for packages is not acceptable. It still doesn't? Haha! I remember ranting about this 10 years ago, with a friend who went to a conference in France… that was dedicated to package management in BSDs. I asked him how I "just upgrade all the packages" (apt-get upgrade). I'd found two-three ways, but couldn't get them to work. He said that yeah there are thre…

On OpenBSD, just do `pkg_add -Uu`.

That's packages only, and with ports you're on your own, right?

Re: BSD vs. Linux (2005)

#344

Post by belorn »

m_mueller wrote: post #248
JoeAltmaier wrote: post #238

Earlier quoted context omitted.

Creative Commons works that way. So its possible.

People keep saying CC, but that license has never been intended for software. Did it ever stand up to a trial in court for this usecase? See also [1]. Why isn't there something like CC NC geared for software? [1] https://wiki.creativecommons.org/index.php/Frequently_Asked_... > We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software li…

Is it important if court has tested the license? A software license is like a will, in that it describes the authors intention in a legal binding document. A infringer would need to prove in court that their activity does not conflict with the requirements of the license, and the words "non-commercial" would be quite hard to sneak around. The main reason that FSF and similar activly advice against such license is primarily because "non-commercial" is ambiguous and there is a clear risk for the recipients/re-distributors if the original author starts to act abusive. A common example I have heard is public schools vs private school, where the later is a commercial activity and the former is common viewed as not. How that would translate to a student using it in a student project would be up in the air.

If I where you, I would instead copy the license of the unreal engine. That is, you don't look at the commercial status but rather on profits from products that include your work. If someone is earning profits, regardless of the nature of the organization who do so, then a cut is required to be given to you. Its simple, it fixes the school problem above, and there is a "industry" example to use if it ever became a court case. The big drawback is that its not an open source compatible license.

Re: BSD vs. Linux (2005)

#345

Post by m_mueller »

erlehmann_ wrote: post #334
m_mueller wrote: post #244

Earlier quoted context omitted.

Yes, but we're at the start again: Only when you don't depend on other GPL software at compile time (and even runtime bindings can be tricky AFAIK). So it only works if all people do is write a bunch of siloes and don't work as a community at all. So, looking at Linux system software as an example, it only works as long as you stay far away from the kernel.

If you depend on software, the authors of the dependencies have done a part of your job for you. GPL basically says the authors only agree to help you on the condition that you also help others. You can always choose not to be a part of such a community, then you will not get help. What is the problem?

For me the problem is that GPL mixes up the requirement of "Open Source" (which I'm fine with) with a requirement that anything depending on it has to be GPL as well (which I have a problem with). Basically, if GPL would allow someone to sell licenses to his software as long as he keeps publishing the sources, it would go a long way to enable a userland application market on top of GNU based kernels.

Gnu.org could even demand a percentage of revenues going towards the GNU foundation. IMO that would make Linux even free-er since it would democratise the way kernel development is funded (i.e. redistribute some of the influence away from the big software corporations who currently chip in). Right now kernel development works fine because you have the right gatekeepers at the top (especially LT), but I wonder what happens when he retires - will some committee take over?

Re: BSD vs. Linux (2005)

#346

Post by digi_owl »

legooolas wrote: post #338
caf wrote: post #333

Earlier quoted context omitted.

systemd isn't part of the kernel at all.

Yet. (Does kdbus count?)

Given that they seem to have given up on kdbus, and is instead developing something called bus1 that appears they are not even planning to submit for inclusion, i find myself thinking that the systemd devs are these days working on enveloping the kernel.

Meaning that you no longer use kernel syscalls, but instead program with systemd in mind and then systemd talks to the kernel as it sees fit.

Just observe their actions regarding session tracking, where they are basically ignoring all data from the kernel about sessions.

Re: BSD vs. Linux (2005)

#347

Post by digi_owl »

zeveb wrote: post #261
AnonymousPlanet wrote: post #164

Earlier quoted context omitted.

> By "outrage" I've meant canonical has developed it because they didn't like gnome shell(they like the innovation-thing). After watching the "we're the only ones who know best, so shut up"-antics of the Gnome developers, I can understand that canonical got cold feet. > Unity has problems with multiple monitors, consumes more RAM and CPU and is also hard to customize. In my experience, setting up multiple monitors wa…

> After watching the "we're the only ones who know best, so shut up"-antics of the Gnome developers, I can understand that canonical got cold feet. If only we could exile the GNOME devs, Canonical & the systemd devs to a desert island, the state of the Linux desktop would be … well, probably not as good but at least it'd be a much more collegial community. To get back to the original topic: the attitudes of the GNOME…

Also OpenBSD devs are happy staying in their sandbox, rather than trying to turn every sandbox in their sandbox.

Re: BSD vs. Linux (2005)

#348

Post by pritambarhate »

tw04 wrote: post #331
ChuckMcM wrote: post #324

Earlier quoted context omitted.

If Apple were to release MacOS for non-Apple hardware I would upgrade to that in a heartbeat. If the Ubuntu 'shell' for the Windows kernel works out I might switch to that as well.

Why not just do a hackintosh?

I had tried it 6years ago. Every OS update used to break the machine. Even USB ports had issues.

Re: BSD vs. Linux (2005)

#349

Post by cgag »

krylon wrote: post #202
cm3 wrote: post #150

Earlier quoted context omitted.

HAMMER1 on DragonflyBSD runs well with little memory, including running dedup. It also has the binary pkg system just like FreeBSD. Also, the DRM drivers are up to date and support current Intel GPUs.

Huh. I had not really looked closely at DragonFly in a while. I had briefly looked at it when setting up my new server, but the fact that HAMMER does not deal with redundancy itself made me stick with FreeBSD/ZFS. On a laptop, however (with an Intel GPU) that is not an issue, as there is only one disk, anyway. I might have to take a look over the summer.

Redundancy as advanced as ZFS can do would be sweet, but if you're ok with something simple, like a two disk setup, you can put a PFS on each and stream one disk to the other.

Re: BSD vs. Linux (2005)

#350

Post by slgeorge »

m_mueller wrote: post #345
erlehmann_ wrote: post #334

Earlier quoted context omitted.

If you depend on software, the authors of the dependencies have done a part of your job for you. GPL basically says the authors only agree to help you on the condition that you also help others. You can always choose not to be a part of such a community, then you will not get help. What is the problem?

For me the problem is that GPL mixes up the requirement of "Open Source" (which I'm fine with) with a requirement that anything depending on it has to be GPL as well (which I have a problem with). Basically, if GPL would allow someone to sell licenses to his software as long as he keeps publishing the sources, it would go a long way to enable a userland application market on top of GNU based kernels. Gnu.org could ev…

You're right, you can't "sell" GPL software. What you mean by "sell" is "grant a license for usage" and that's exactly what the GPL or a similar FOSS license does. So the two things conflict. Really you're describing a situation that the GPL is not designed for.

Your desires are more inline with Microsoft 'shared source' type of situations.

The GPL and the FSF's world-view isn't particularly aligned with what you want (I believe). Either use the GPL and live with the constraints, or use something else. Something else's that come-up in a GPL but commercial context are:

a. Service or Support. You've said you want to be paid for creating the software and not for providing services, so this one is out. Note that SaaS is now the easiest way to achieve what you want.

b. Dual licensing. You said "you can't depend on GPL software then". Well yeah, because GPL is about a commons of equals 'sharing' and you want to charge for sharing - so you don't get to use other people's stuff for free. Seems fair to me.

But, your actual concern isn't really valid - there are lots of things you can write without depending on GPL software. This is probably more realistic than you think.

c. Open core. Someone described this to you earlier, I think.

d. Validation and/or IPR. Probably outside the boundaries of most individual developers. But think of the way that Java is licensed on the basis of it being a 'valid' implementation and then IPR and trademarks.

Post reply on HN