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

OpenSolaris fork imminent?

opensolaris.org

Post reply on HN
Print view View original

51–57 of 57 posts

Re: OpenSolaris fork imminent?

#51

Post by ssmoot »

jcsalterego wrote: post #24
vegai wrote: post #11

Earlier quoted context omitted.

Pretty much no reason. The deal breakers you mention have also been ported to FreeBSD and are said to be rather stable already.

As adbge mentions elsewhere, the latest ZFS package in FreeBSD is lagging OpenSolaris's. http://hackerne.ws/item?id=1567463 (or scroll down)

Data de-dupe is FUBAR. It's why snv_134, which was supposed to be final was scrapped.

I hadn't heard of a FreeBSD kernel issue, but if that's true, it might just be for the best for the next 6 months at least. de-dupe is kinda a useless feature if you're not a hosting company anyway. A hosting company could take advantage of storing tons of mostly-the-same VMs. It's not the few hundred GB in our dozens of base VM images that concerns me though. It's the terra-bytes of multimedia and databases.

Plus de-dupe takes a lot of RAM. A lot. There was a time where it would've been very nice, but as it stands, it's really a niche product to come up with a situation where it's RAM requirements, and it's rather small storage savings might make sense.

Re: OpenSolaris fork imminent?

#52

Post by ssmoot »

c00p3r wrote: post #17
nailer wrote: post #8

Earlier quoted context omitted.

I've modded you back up as I have the same question, albeit I think some explanation would help: FreeBSD has the good bits of the Solaris kernel - ZFS and DTrace - and the common Solaris 10 userspace - toolchain, packaging, etc. - aren't particularly up to date.

Add to this an idiotic attempt to replace SystemV startup scripts with some insanely non-obvious java-based (of course!) crap, badly ported in a great hurry outdated 32-bit userland (when at the same time x86_64 version of Fedora or FreeBSD-ports were several years old), some in-house designed and quite alien packaging system (pkg) and so on. It is dead. As dead as Irix or Tru64 or even OpenVMS.

Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best.

I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (process or file-based). The SMF covers these bases very well.

Runit seems to come closest on the service side, but it's not nearly as well documented. Monit is almost a suitable substitute (even though that's not really it's goal), but robust dependency support is lacking last I checked.

Re: OpenSolaris fork imminent?

#53

Post by rbanffy »

wwortiz wrote: post #33
rbanffy wrote: post #26

Earlier quoted context omitted.

No. Debian and Fedora have just fine package managers. What they can't do is boot from a ZFS file system. I am implying Solaris and FreeBSD (the other OSs that boot from ZFS, AFAIK) don't have a sane packaging system.

I am curious what you find wrong with FreeBSD's package management, or is it in reference to packages and does not include ports?

Source-based packaging is slower than binary packages. The binary package system, although it exists, is not as simple to use.

In Red Hat-ish distros, I can do "yum update". In Debian-ish distros, I can run "aptitude safe-upgrade". On Debian, I can even do a dist-upgrade and update the box to a new release without having to reinstall it (or boot into the installer). Everything is downloaded, installed and, if needed, restarted. Very close to zero downtime.

Re: OpenSolaris fork imminent?

#54

Post by nailer »

ssmoot wrote: post #52
c00p3r wrote: post #17

Earlier quoted context omitted.

Add to this an idiotic attempt to replace SystemV startup scripts with some insanely non-obvious java-based (of course!) crap, badly ported in a great hurry outdated 32-bit userland (when at the same time x86_64 version of Fedora or FreeBSD-ports were several years old), some in-house designed and quite alien packaging system (pkg) and so on. It is dead. As dead as Irix or Tru64 or even OpenVMS.

Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best. I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (proces…

> Solaris SMF is actually one of the best things about Solaris (IMO)?

XML config files? Java when a regular Unix system language like C or Python (or Perl for older folks) would suffice?

Re: OpenSolaris fork imminent?

#55

Post by ssmoot »

nailer wrote: post #54
ssmoot wrote: post #52

Earlier quoted context omitted.

Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best. I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (proces…

> Solaris SMF is actually one of the best things about Solaris (IMO)? XML config files? Java when a regular Unix system language like C or Python (or Perl for older folks) would suffice?

XML isn't the best perhaps. But it's not a road-block either. New config files are always new.

And who cares what it's implemented in as long as it doesn't fall over? I mean, ideally sure. C FTW on resource utilization, but honestly, if the choice is between something that's a bit of a pig, eating up 100MB of RAM vs what...? Really simply put: There is no competition that checks the same boxes that I'm aware of.

I'd be genuinely grateful if you can show me an alternative, especially for GNU/Linux and FreeBSD, but most of the alternatives are new early-phase projects with grand goals that may never materialize, or unmaintained.

So sure, SMF isn't perfect. What's better?

Re: OpenSolaris fork imminent?

#56

Post by c00p3r »

ssmoot wrote: post #52
c00p3r wrote: post #17

Earlier quoted context omitted.

Add to this an idiotic attempt to replace SystemV startup scripts with some insanely non-obvious java-based (of course!) crap, badly ported in a great hurry outdated 32-bit userland (when at the same time x86_64 version of Fedora or FreeBSD-ports were several years old), some in-house designed and quite alien packaging system (pkg) and so on. It is dead. As dead as Irix or Tru64 or even OpenVMS.

Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best. I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (proces…

Go back to school and learn the basic principles on which UNIX was built upon.

Try to recognize the differences between text file and XML file.

Try to understand the difference between 'file /bin/sh' , 'ldd /bin/sh' and /usr/bin/java.

Re: OpenSolaris fork imminent?

#57

Post by ssmoot »

c00p3r wrote: post #56
ssmoot wrote: post #52

Earlier quoted context omitted.

Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best. I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (proces…

Go back to school and learn the basic principles on which UNIX was built upon. Try to recognize the differences between text file and XML file. Try to understand the difference between 'file /bin/sh' , 'ldd /bin/sh' and /usr/bin/java.

What is your argument exactly? Do you even understand what I said?

Here's the output of one of our services:

fmri svc:/application/harbor/unicorn:default name Unicorn Rack Server enabled true state online next_state none state_time Sat Aug 07 12:52:45 2010 logfile /var/svc/log/application-harbor-unicorn:default.log restarter svc:/system/svc/restarter:default contract_id 18664 dependency require_all/none svc:/milestone/network:default (online) dependency require_all/none svc:/system/filesystem/local:default (online) dependency require_all/refresh file://localhost/var/harbor/unicorn.conf (online) dependency require_all/refresh file://localhost/var/harbor/config.ru (online) dependency require_all/refresh file://localhost/var/harbor/log (online)

See the dependencies? It took one of my guys all of a couple hours to grasp the documentation and set this up. Without ever having seen it before.

If you want the plain XML, just 'svccfg export unicorn'

You're a fool if you think a maintained, documented simple service like this has no value just because angle-brackets scare and confuse you.

If you had a more open mind, you might even ask yourself why it was done this way? Perhaps it's because with XML you can spend all of a few minutes in practically any programming language and have something that can manage the services?

And perhaps that might come in handy if you were managing a lot of servers, or building a cluster that you wanted to manage, install, and update services on?

Sure you could go the usual route of inventing your own syntax. tcl, lisp, or python compatible if you're lucky. Or you might just consider that maybe interoperability isn't the fall of Rome while you dismiss one of the most robust service management tools around just because you might have to write a bit of XML.

Unfortunately I didn't goto school. I did it the old fashioned way. I read people smarter than me. I'm glad I could do the same for you. :-)

Post reply on HN