“Hooray! We have forked an already small community into yet another smaller community because…”
Well, the “because” doesn’t really matter, even though they make extremely valid points! In an already incredibly fragmented community (how many derivatives of OpenSolaris does this make?) this makes the problem bigger…
I don’t follow illumos very closely, but are there reasons that community won’t assist in pushing towards solving the concerns that sparked unleashed? Surely illumos is also an operating system that “developers want to use,” no?
If the illumos community were healthy I would agree with you and I wouldn’t have bothered to create this fork. Sadly, I think the illumos community has problems and the people that truly have a lot of say where the project goes either don’t see them or like the status quo.
Two years ago when I started Unleashed, I had a dilemma: should I fork illumos or ditch it for one of the BSDs. When I realized that there were other people that were just as unhappy with the (lack of) direction illumos had, making a fork sounded like a good option. That’s how we got here.
Now where do we go from here is an open question. It is completely possible that Unleashed will fizzle, at which point I can say that no real harm was done. The illumos community will remain as small as it was two days ago, with major contributors like Delphix bailing on illumos in favor of Linux. If Unleashed takes off and in the process kills off illumos, the overall ecosystem will be better off. There might be a person or two grumpy that they can’t run their emacs binary from 1994, but in my opinion that is a small price to pay.
Surely illumos is also an operating system that “developers want to use,” no?
That is the reason I considered and ultimately went with a fork instead of bailing on it. The technology in Solaris/OpenSolaris/illumos/Unleashed is great, and I didn’t want to give it up. I wanted to give up the hugely inefficient and ultimately counter-productive contribution process.
Thanks for taking the time to respond. I know my post probably came off as aggressive, and if I’m honest, it was half intended to be. I think forks are very disruptive, and wish, of course, to minimize these sorts of things when at all possible.
When I realized that there were other people that were just as unhappy with the (lack of) direction illumos had, making a fork sounded like a good option.
This makes total and reasonable sense. I didn’t mean to imply that you hadn’t thought this through! And appreciate that you used it as a sort of last resort.
That is the reason I considered and ultimately went with a fork instead of bailing on it. The technology in Solaris/OpenSolaris/illumos/Unleashed is great, and I didn’t want to give it up. I wanted to give up the hugely inefficient and ultimately counter-productive contribution process.
Thanks for doing what you’re doing, and I wish Unleashed success (and maybe either domination or an eventual merge of the communities again)!
No problem. I really had no choice - someone on the internet was “wrong” ;)
I know my post probably came off as aggressive, and if I’m honest, it was half intended to be.
The phrasing certainly made me go “urgh, not one of those…” but it sounds like we both agree that forks are disruptive, but you think that it’s a negative thing while I think it is a positive thing. A reasonable difference of opinion.
Thanks for doing what you’re doing, and I wish Unleashed success (and maybe either domination or an eventual merge of the communities again)!
The phrasing certainly made me go “urgh, not one of those…”
There’s really nothing I can offer as a legitimate excuse for that. I’m sorry.
but you think that it’s a negative thing while I think it is a positive thing. A reasonable difference of opinion.
The additional context you’ve provided makes me feel that it probably is the right, and positive choice in this case. I’m not vehemently against forks if there’s a legitimately good reason [and just to be clear, moving on from supporting legacy stuff is the important divergence I’m seeing, as it frees up resources to move faster]. I am against forks that don’t offer some radical divergence in philosophy, though. These are often rooted from deep bikeshedding on topics that don’t matter in the grand scheme of things.
Two examples of justified forks in my opinion: @rain1 recently forked filezilla because it was incorporating “unwanted extra nonfree software.” Devuan is a fork of Debian that replaces systemd – a topic that is far beyond bikeshedding at this point, as it’s had (and will continue to have) a drastic effect on the portability of software to other ecosystems.
In my mind, there are two types of forks we’re talking about. One of them is a “fork” on github, where I clone the repo, make some changes, contribute it back to the original author (or maybe not!), and live a happy life. These types of forks are almost always ok. It’s the “You do you, man. You do you.” response.
The other “fork” is far more challenging, and far more likely to cause a rift in spacetime. Those are the large, and by all accounts, successful projects that as a result divide a community, and make it difficult for users and would be contributors to find the right thing to use. These projects fork very publicly, and are rather uncomfortable, to be honest.
In many cases, these forks occurred because egos were hurt (I wanted it yellow) – a social issue – not a technical issue. In other cases, there’s a large philosophical difference that impacts the general direction of the technology. This may be licensing, whether or not to support obscure platforms, a radical new idea or focus… etc. In all cases, even if there are legitimately great outcomes (OpenBSD comes to mind), there’s a period of confusion and frustration from users who are now forced to choose where to put their effort. They are forced into taking sides, and that’s unfair.
These are marketing concerns. Market share issues, to be precise.
They are valid for open source projects that are basically marketing tools, but they are pointless for free software that maximizes hackers’ freedom to hack.
Feeling the need to justify a fork, is the first step towards asking permission.
The PATENTS file in projects like Fuchsia’s kernel sources just push for that.
Sorry, my friend. Most people don’t share your principles on what a ‘hack,’ or a ‘hacker’ is. More often than not, the people using, and writing software care more about getting the job done quickly, and without frustration, and a fork makes that harder. It doesn’t matter how you classify it.
people using, and writing software care more about getting the job done quickly, and without frustration
And this is fine!
But, my friend, you need to understand the tools you use!
If you pick up a free software that is distributed “WITHOUT ANY WARRANTY” just because it’s free of charge, and you completely miss the culture of the people who develop it, you won’t get your job done. Same if you pick an open source software controlled by Google (or whoever) and you fork it to successfully challenge their market share.
In both cases, you’ll face surprises, unexpected costs and frustration.
Understanding the environment you operate in, is strategic to “get the job done”.
Most people don’t share your principles on what a ‘hack,’ or a ‘hacker’ is.
Interesting! Do you have world-wide statistics to prove such claim?
Not that it matters: “principles” stand to “artifacts” like “postulates” stand to “theorems”. How many people accept the postulates/principles is irrelevant.
I know that some people don’t share my principles. And I’m fine with it.
Do you know that some people don’t share your principles?
Are you fine with it?
But, my friend, you need to understand the tools you use!
If you pick up a free software that is distributed “WITHOUT ANY WARRANTY” just because it’s free of charge, and you completely miss the culture of the people who develop it, you won’t get your job done. Same if you pick an open source software controlled by Google (or whoever) and you fork it to successfully challenge their market share.
In both cases, you’ll face surprises, unexpected costs and frustration
I read this several times and can’t figure out what you’re saying.
Why do I need to understand the culture of a tool I use? As long as it fulfills my technical needs and I know what I’m prohibited to do by law, I can use it to get my job done.
There are ways around much of these concerns. I have a support contract, or trust in a distribution (say, Canonical for Ubuntu or Red Hat), which provides vuln disclosures, and updates for me to apply. I have a development process that includes QA, and automated CI infrastructure so that breaking changes are caught before production… etc.
But, to the meta point:
But, my friend, you need to understand the tools you use!
Demonstrably this is not at all true. It’s easy to do a survey of 100 people – 10 people even, and ask them if they understand their tools. How are their tools implemented? How does the relational database they store and query data into/from store data on disk? How does the map type work in their favorite language? How does the VM work? How does the ORM work? How does the templating language they use work? How does the image processing library they use work to resize images, or rotate images, or whatever work? How does TensorFlow do all it does?
What you’ll find is that a large portion of engineers have no idea how things work. And they don’t need to know. Their job is to build CRUD apps for people who could care less if something takes a little bit longer. The developer themselves, in many cases, could care less about BTREE indexes vs. HASH indexes, and doesn’t really know the difference. For the amount of data they manipulate, doing full table scans 3 times an hour (because they literally have 3 queries an hour) is completely sane, reasonable, and still puts a smile on the face of the Administrative assistant who no longer has to go to a type writer to type out a bunch of labels. Or, who no longer has to print 10,000 college applications to give to admissions reviewers… or any number of other tasks where even the worst technology choices, recommended by underskilled developers can make a ginormous (and) positive difference on the process.
Sure, but the simplest one is to understand the tools you use.
And actually, trusting Debian (or OpenBSD or whatever) or signing support a contract with Canonical (or Red Hat or Microsoft or whatever) requires the cultural understanding of such people I was talking about.
Demonstrably this is not at all true. […]
…even the worst technology choices, recommended by underskilled developers can make a ginormous (and) positive difference on the process.
Practically you are saying: “everyone can become rich without working: just win the lottery!”. Well, this is not false. Stick on boring low-hanging fruits all your life and you will never face the issues that a professional developer has to consider every day.
What you describe is not to “get the job done”.
People die because of people who work this way.
In Italy we use to say: “even a broken clock can be right twice a day”.
Yes, incompetent developers can occasionally improve the life of someone, but for most of time, they just mess up things beyond repair.
Practically you are saying: “everyone can become rich without working: just win the lottery!”. Well, this is not false. Stick on boring low-hanging fruits all your life and you will never face the issues that a professional developer has to consider every day.
What you describe is not to “get the job done”.
People die because of people who work this way.
I believe this comment really lacks perspective. What you are saying is the Shamar-style of development is the only correct style of development and anyone not doing it that way is not only doing it wrong but putting people’s lives at risk.
The industry I work in produces a lot of software and consumes a lot of software, however no company in this industry would consider itself a tech company. We have people whose job title is “Software Engineer”. But, for the most part, they make pretty bad technical decisions and are fairly unskilled relative to the engineers at most tech companies. But, they aren’t “trying to get rich without working” or “win the lottery”. They are very hard working. The industry just has a different set of values where the software is incidental to the actual problem the company is solving. A lot of the things you brought up in an earlier post about why one needs to understand the culture of the software they consume doesn’t actually apply in the industry I’m in. Security updates and backdoors are almost never going to be a concern because these systems are not open to the outside. The data they consume is entirely generated and processed inside the walls of the company. In the industry I’m in, we’re actually saving lives too! I mean that literally.
I hate to use this word, but your comment is elitist. Anyone not solving problems how you say is not a professional and just causing damage “beyond repair”. Your comment lacks humility and perspective yet is extremely assertive. It might be worth stepping back and questioning if what you assert so strongly is an ideal, a belief, or reality. Or perhaps it’s a challenge with the language and you don’t realize how assertive your comments sound relative to how assertive you meant them to be. But insisting people not following your development principles are killing people is a pretty strong statement, in any case.
But insisting people not following your development principles are killing people is a pretty strong statement, in any case.
I was not talking about software development in particular.
Incompetent engineers build bridges that fell off.
Incompetent phyisicians do not cure mortal deseases properly. And so on.
They can get some work done, but it’s lucky, like winning te lottery.
On the contrary!
I mean that to make a choice you need competence.
I’m saying that only a competent professional that knows the tools she use can really “get the job done”.
An incompetent one can be lucky some times, but you cannot trust her products and thus the job is not done.
Or perhaps it’s a challenge with the language
Actually, I’m rather surprised by the opposition such a simple and obvious concept is facing. All other craftmen I know (the real ones, not the software ones) agree that it takes years to “own” their tools.
Probably we have diverged too much from the original topic, and we are facing a deep cultural mismatch.
In Europe (that, let me say, is not living up to its own values these days) we are used to be very diverse and inclusive (note: it took centuries of wars, rapes, debates, commerce, poetry, science, curiosity and many other contaminations to get here).
But we do not meld the meaning of words just to include more people.
We clearly see and state the differences, and happily talk about them.
And this is not elitism, it’s efficient communication.
When we say “job” or “done” we convey a precise message.
And if a bridge fell off and kills someone, we call the engineers who built it liars because the job was not done. At times they even stop being called engineers at all.
You don’t give an inch, do you? I’ve explicitly said that I work in an industry that does not do software development like you have expressed it should be done and your response is to keep on insisting on it. On top of that, you did this annoying thing where this discussion has clearly been about software development but when I pushed back you move the goal post and start talking about bridges and medicine. It’s extremely challenging and frustrating to communicate with you, I need to work on not doing that. Thanks for the discussion, it was insightful for myself.
Looks like someone got a degree in being right on the Internet! There’s no point in engaging with you, and if there was a feature to block users, I would make use of it.
If you lack arguments to support your assuptions, I can suggest to simply state such assumptions clearly. For example:
Users and companies are entitled to get work and value from software developers for free, because they are in a rush to get their job done.
FS and OSS forks hurts this right.
I would deeply disagree on such premise.
But I wouldn’t argue against the conclusions.
I just spent 30 minutes carefully crafting a response to your absurd notion that everyone must be highly skilled or people will die. But, it’s just not worth it. You’ll find a way to twist it into something it’s not, and yell loudly about how I’m wrong without considering that you may be shortsighted in your assumptions.
Question that I have that isn’t clear from the post. Do you intend to maintain enough compat with Illumos that you would be able to get improvements that were done n something like SmartOS? Are you planning on continuing to pulls changes from Illumos? Planning to try contributing changes back? Or is this a hard fork where you don’t imagine there would be cross pollination?
Source-level compat, yes until it stops to make sense. Binary compat, no.
I’ll continue git-pull from illumos-gate until it starts to be too cumbersome due to divergence. Once that happens, I’ll probably still take commits from illumos-gate but I’ll be more selective. In addition to illumos-gate, we cherry-pick changes from the illumos downstreams (omnios, illumos-joyent, etc.). This is open source, if those repos have good changes I’d be stupid not to take them because they were authored “outside”.
I have no plan to get changes back into illumos, however the code is open so others can do it. As an example, Toomas Soome took one of the cleanups in Unleashed and got it into illumos-gate (87bdc12930bfa66277c45510e399f8a01e06c376). He also has a work-in-progress to get our cpio-based boot_archives into illumos, but I don’t know the status of that.
We are definitely on that path. In SmartOS (a downstream project in the illumos family) we’re doing some work right now to make it easier to run both gcc 4.4.X and gcc 6 (as what we call a shadow compiler) in our build process. Eventually, when we’re sure it works properly, we’ll make the transition forward.
illumos is slowly fixing up the code to get newer gcc working. There has been a lot of fixups to make gcc7/8 happy, but neither Unleashed nor illumos are close to building with a compiler newer than gcc 4.4.4. (Unleashed gets those fixups via periodic git-pulls.)
In Unleashed, given our limited resources, we haven’t specifically targeted a compiler update yet, but we have removed support for Sun Studio (cc and lint) to simplify the transition. If anyone is interested, the “compiler update project” is up for grabs. :)
Things OP has listed look reasonable and needed, in fact illumos needs the distribution that is described in here, but I don’t know how to achieve that. As @apg said this is just another fragmentation of already small and fragmented community.
SmartOS being the biggest fish in the tank, being backed and developed by Joyent is probably the best option, but it is not kind of general-purpose-developer Operating System. I have played with illumos, looked at it source code, and no doubt it is the best operating system I have seen (yes I am very young, millennial, and I don’t like linux), but as of now I see FreeBSD to be the best option.
I would really like small, efficient and nifty operating system, that goes somewhere in between FreeBSD and OpenBSD but in illumos land. :)
I would really like small, efficient and nifty operating system, that goes somewhere in between FreeBSD and OpenBSD but in illumos land. :)
That’s kind of the goal. I personally lean toward FreeBSD on that spectrum, but one of the other Unleashed devs is a big fan of OpenBSD so he brings that point of view to the project.
(Preface: I didn’t know much, and still don’t, about the *Solaris ecosystem.)
So it seems like the evolution of *Solaris took an approach closer to Linux? Where there’s a core chunk of the OS (kernel and core build toolchain?) that is maintained as its own project. Then there’s distributions built on top of illumos (or unleashed) that make them ready-to-use for endusers?
For some reason, I had assumed it was closer to the *BSD model where illumos is largely equivalent to something like FreeBSD.
If I wanted to play with a desktop-ready distribution, what’s my best bet? SmartOS appears very server oriented - unsurprising given *Solaris was really make more in-roads there in recent years. OpenIndiana?
If Linux (kernel only) and BSD (whole OS) are the extremes of the scale, illumos is somewhere in the middle. It is a lot more than just a kernel, but it lacks some things to even build itself. It relies on the distros to provide those bits.
Historically, since Solaris was maintained by one corporation with lots of release engineering resources and many teams working on subsets of the OS as a whole, it made sense to divide it up into different pieces. The most notable one being the “OS/Net consolidation” which is what morphed into what is now illumos.
Unleashed is still split across more than one repo, but in a way it is closer to the BSD way of doing things rather than the Linux way.
Hope this helps clear things up!
If I wanted to play with a desktop-ready distribution, what’s my best bet? SmartOS appears very server oriented - unsurprising given *Solaris was really make more in-roads there in recent years. OpenIndiana?
OI would be the easiest one to start with on a desktop. People have gotten Xorg running on OmniOS (and even SmartOS), but it’s extra work vs. just having it.
illumos itself doesn’t have an actual release. You’re expected to use one of its distributions as far as I can tell, which should arguably be called “derivatives” instead. OpenIndiana seems to be the main desktop version.
I don’t know. I know there are some people who run SmartOS on their desktop, but I get the feeling it’s not targeting that use case, or at least there isn’t a lot of work going into supporting it.
Sob!
Well… I will not surrender! :-D
“Hooray! We have forked an already small community into yet another smaller community because…”
Well, the “because” doesn’t really matter, even though they make extremely valid points! In an already incredibly fragmented community (how many derivatives of OpenSolaris does this make?) this makes the problem bigger…
I don’t follow illumos very closely, but are there reasons that community won’t assist in pushing towards solving the concerns that sparked unleashed? Surely illumos is also an operating system that “developers want to use,” no?
As always, we’re happy to work with people who want to push changes to illumos-gate!
xkcd 1095 seems relevant. :^)
Yeah, maybe. :)
If the illumos community were healthy I would agree with you and I wouldn’t have bothered to create this fork. Sadly, I think the illumos community has problems and the people that truly have a lot of say where the project goes either don’t see them or like the status quo.
Two years ago when I started Unleashed, I had a dilemma: should I fork illumos or ditch it for one of the BSDs. When I realized that there were other people that were just as unhappy with the (lack of) direction illumos had, making a fork sounded like a good option. That’s how we got here.
Now where do we go from here is an open question. It is completely possible that Unleashed will fizzle, at which point I can say that no real harm was done. The illumos community will remain as small as it was two days ago, with major contributors like Delphix bailing on illumos in favor of Linux. If Unleashed takes off and in the process kills off illumos, the overall ecosystem will be better off. There might be a person or two grumpy that they can’t run their emacs binary from 1994, but in my opinion that is a small price to pay.
That is the reason I considered and ultimately went with a fork instead of bailing on it. The technology in Solaris/OpenSolaris/illumos/Unleashed is great, and I didn’t want to give it up. I wanted to give up the hugely inefficient and ultimately counter-productive contribution process.
Happy hacking!
Thanks for taking the time to respond. I know my post probably came off as aggressive, and if I’m honest, it was half intended to be. I think forks are very disruptive, and wish, of course, to minimize these sorts of things when at all possible.
This makes total and reasonable sense. I didn’t mean to imply that you hadn’t thought this through! And appreciate that you used it as a sort of last resort.
Thanks for doing what you’re doing, and I wish Unleashed success (and maybe either domination or an eventual merge of the communities again)!
No problem. I really had no choice - someone on the internet was “wrong” ;)
The phrasing certainly made me go “urgh, not one of those…” but it sounds like we both agree that forks are disruptive, but you think that it’s a negative thing while I think it is a positive thing. A reasonable difference of opinion.
Thanks, that’s the idea :)
There’s really nothing I can offer as a legitimate excuse for that. I’m sorry.
The additional context you’ve provided makes me feel that it probably is the right, and positive choice in this case. I’m not vehemently against forks if there’s a legitimately good reason [and just to be clear, moving on from supporting legacy stuff is the important divergence I’m seeing, as it frees up resources to move faster]. I am against forks that don’t offer some radical divergence in philosophy, though. These are often rooted from deep bikeshedding on topics that don’t matter in the grand scheme of things.
Two examples of justified forks in my opinion: @rain1 recently forked filezilla because it was incorporating “unwanted extra nonfree software.” Devuan is a fork of Debian that replaces systemd – a topic that is far beyond bikeshedding at this point, as it’s had (and will continue to have) a drastic effect on the portability of software to other ecosystems.
No worries. Hopefully my initial response didn’t come across as too harsh either. If it did, my apologies.
Agreed. Although sometimes it is hard to tell if there is a justification for the fork.
I wonder when we started to need a justification.
Why?
You do you, man. You do you.
In my mind, there are two types of forks we’re talking about. One of them is a “fork” on github, where I clone the repo, make some changes, contribute it back to the original author (or maybe not!), and live a happy life. These types of forks are almost always ok. It’s the “You do you, man. You do you.” response.
The other “fork” is far more challenging, and far more likely to cause a rift in spacetime. Those are the large, and by all accounts, successful projects that as a result divide a community, and make it difficult for users and would be contributors to find the right thing to use. These projects fork very publicly, and are rather uncomfortable, to be honest.
In many cases, these forks occurred because egos were hurt (I wanted it yellow) – a social issue – not a technical issue. In other cases, there’s a large philosophical difference that impacts the general direction of the technology. This may be licensing, whether or not to support obscure platforms, a radical new idea or focus… etc. In all cases, even if there are legitimately great outcomes (OpenBSD comes to mind), there’s a period of confusion and frustration from users who are now forced to choose where to put their effort. They are forced into taking sides, and that’s unfair.
These are marketing concerns. Market share issues, to be precise.
They are valid for open source projects that are basically marketing tools, but they are pointless for free software that maximizes hackers’ freedom to hack.
Feeling the need to justify a fork, is the first step towards asking permission.
The PATENTS file in projects like Fuchsia’s kernel sources just push for that.
Sorry, my friend. Most people don’t share your principles on what a ‘hack,’ or a ‘hacker’ is. More often than not, the people using, and writing software care more about getting the job done quickly, and without frustration, and a fork makes that harder. It doesn’t matter how you classify it.
And this is fine!
But, my friend, you need to understand the tools you use!
If you pick up a free software that is distributed “WITHOUT ANY WARRANTY” just because it’s free of charge, and you completely miss the culture of the people who develop it, you won’t get your job done. Same if you pick an open source software controlled by Google (or whoever) and you fork it to successfully challenge their market share.
In both cases, you’ll face surprises, unexpected costs and frustration.
Understanding the environment you operate in, is strategic to “get the job done”.
Interesting! Do you have world-wide statistics to prove such claim?
Not that it matters: “principles” stand to “artifacts” like “postulates” stand to “theorems”. How many people accept the postulates/principles is irrelevant.
I know that some people don’t share my principles. And I’m fine with it.
Do you know that some people don’t share your principles?
Are you fine with it?
I read this several times and can’t figure out what you’re saying.
Why do I need to understand the culture of a tool I use? As long as it fulfills my technical needs and I know what I’m prohibited to do by law, I can use it to get my job done.
Some example of the issues you might face:
and so on…
You could ignore the culture of tools you get for free, and be lucky.
But in my job, I would call that short-sight and unprofessional.
Software is not like an hammer: even if you take it free of charges, there are strings attached.
There are ways around much of these concerns. I have a support contract, or trust in a distribution (say, Canonical for Ubuntu or Red Hat), which provides vuln disclosures, and updates for me to apply. I have a development process that includes QA, and automated CI infrastructure so that breaking changes are caught before production… etc.
But, to the meta point:
Demonstrably this is not at all true. It’s easy to do a survey of 100 people – 10 people even, and ask them if they understand their tools. How are their tools implemented? How does the relational database they store and query data into/from store data on disk? How does the map type work in their favorite language? How does the VM work? How does the ORM work? How does the templating language they use work? How does the image processing library they use work to resize images, or rotate images, or whatever work? How does TensorFlow do all it does?
What you’ll find is that a large portion of engineers have no idea how things work. And they don’t need to know. Their job is to build CRUD apps for people who could care less if something takes a little bit longer. The developer themselves, in many cases, could care less about BTREE indexes vs. HASH indexes, and doesn’t really know the difference. For the amount of data they manipulate, doing full table scans 3 times an hour (because they literally have 3 queries an hour) is completely sane, reasonable, and still puts a smile on the face of the Administrative assistant who no longer has to go to a type writer to type out a bunch of labels. Or, who no longer has to print 10,000 college applications to give to admissions reviewers… or any number of other tasks where even the worst technology choices, recommended by underskilled developers can make a ginormous (and) positive difference on the process.
Sure, but the simplest one is to understand the tools you use.
And actually, trusting Debian (or OpenBSD or whatever) or signing support a contract with Canonical (or Red Hat or Microsoft or whatever) requires the cultural understanding of such people I was talking about.
Practically you are saying: “everyone can become rich without working: just win the lottery!”. Well, this is not false. Stick on boring low-hanging fruits all your life and you will never face the issues that a professional developer has to consider every day.
What you describe is not to “get the job done”.
People die because of people who work this way.
In Italy we use to say: “even a broken clock can be right twice a day”.
Yes, incompetent developers can occasionally improve the life of someone, but for most of time, they just mess up things beyond repair.
I believe this comment really lacks perspective. What you are saying is the Shamar-style of development is the only correct style of development and anyone not doing it that way is not only doing it wrong but putting people’s lives at risk.
The industry I work in produces a lot of software and consumes a lot of software, however no company in this industry would consider itself a tech company. We have people whose job title is “Software Engineer”. But, for the most part, they make pretty bad technical decisions and are fairly unskilled relative to the engineers at most tech companies. But, they aren’t “trying to get rich without working” or “win the lottery”. They are very hard working. The industry just has a different set of values where the software is incidental to the actual problem the company is solving. A lot of the things you brought up in an earlier post about why one needs to understand the culture of the software they consume doesn’t actually apply in the industry I’m in. Security updates and backdoors are almost never going to be a concern because these systems are not open to the outside. The data they consume is entirely generated and processed inside the walls of the company. In the industry I’m in, we’re actually saving lives too! I mean that literally.
I hate to use this word, but your comment is elitist. Anyone not solving problems how you say is not a professional and just causing damage “beyond repair”. Your comment lacks humility and perspective yet is extremely assertive. It might be worth stepping back and questioning if what you assert so strongly is an ideal, a belief, or reality. Or perhaps it’s a challenge with the language and you don’t realize how assertive your comments sound relative to how assertive you meant them to be. But insisting people not following your development principles are killing people is a pretty strong statement, in any case.
I was not talking about software development in particular.
Incompetent engineers build bridges that fell off.
Incompetent phyisicians do not cure mortal deseases properly. And so on.
They can get some work done, but it’s lucky, like winning te lottery.
As for software, I do not means that a competent software developer cannot adopt a cheap half-working solution instead of an expensive “right” one (whatever it means in the context).
On the contrary!
I mean that to make a choice you need competence.
I’m saying that only a competent professional that knows the tools she use can really “get the job done”.
An incompetent one can be lucky some times, but you cannot trust her products and thus the job is not done.
Actually, I’m rather surprised by the opposition such a simple and obvious concept is facing. All other craftmen I know (the real ones, not the software ones) agree that it takes years to “own” their tools.
Probably we have diverged too much from the original topic, and we are facing a deep cultural mismatch.
In Europe (that, let me say, is not living up to its own values these days) we are used to be very diverse and inclusive (note: it took centuries of wars, rapes, debates, commerce, poetry, science, curiosity and many other contaminations to get here).
But we do not meld the meaning of words just to include more people.
We clearly see and state the differences, and happily talk about them.
And this is not elitism, it’s efficient communication.
When we say “job” or “done” we convey a precise message.
And if a bridge fell off and kills someone, we call the engineers who built it liars because the job was not done. At times they even stop being called engineers at all.
You don’t give an inch, do you? I’ve explicitly said that I work in an industry that does not do software development like you have expressed it should be done and your response is to keep on insisting on it. On top of that, you did this annoying thing where this discussion has clearly been about software development but when I pushed back you move the goal post and start talking about bridges and medicine. It’s extremely challenging and frustrating to communicate with you, I need to work on not doing that. Thanks for the discussion, it was insightful for myself.
Looks like someone got a degree in being right on the Internet! There’s no point in engaging with you, and if there was a feature to block users, I would make use of it.
I’m sorry about this.
If you lack arguments to support your assuptions, I can suggest to simply state such assumptions clearly. For example:
I would deeply disagree on such premise.
But I wouldn’t argue against the conclusions.
Did you just tell me to go fuck myself?
Ok, this must really be a language problem.
I cannot find a translation of what I wrote that can be interpreted that way!
Anyway: No, I’m not telling you to fuck yourself.
I just spent 30 minutes carefully crafting a response to your absurd notion that everyone must be highly skilled or people will die. But, it’s just not worth it. You’ll find a way to twist it into something it’s not, and yell loudly about how I’m wrong without considering that you may be shortsighted in your assumptions.
I’m sorry for the time you wasted.
I do not think that “everyone must be highly skilled or people will die”.
I think that everyone should be professional in his own job.
Which, at the bare minimium, means to understand the tools you use.
I woudn’t even engage if I woud not assume this to be possible: there would be nothing to learn.
[Comment removed by moderator pushcx: Removing double-post.]
Question that I have that isn’t clear from the post. Do you intend to maintain enough compat with Illumos that you would be able to get improvements that were done n something like SmartOS? Are you planning on continuing to pulls changes from Illumos? Planning to try contributing changes back? Or is this a hard fork where you don’t imagine there would be cross pollination?
Good questions!
Hopefully I covered everything.
Is upstream illumos looking into modern compiler support?
We are definitely on that path. In SmartOS (a downstream project in the illumos family) we’re doing some work right now to make it easier to run both gcc 4.4.X and gcc 6 (as what we call a shadow compiler) in our build process. Eventually, when we’re sure it works properly, we’ll make the transition forward.
(Disclaimer: Unleashed is my creation.)
illumos is slowly fixing up the code to get newer gcc working. There has been a lot of fixups to make gcc7/8 happy, but neither Unleashed nor illumos are close to building with a compiler newer than gcc 4.4.4. (Unleashed gets those fixups via periodic git-pulls.)
In Unleashed, given our limited resources, we haven’t specifically targeted a compiler update yet, but we have removed support for Sun Studio (cc and lint) to simplify the transition. If anyone is interested, the “compiler update project” is up for grabs. :)
Things OP has listed look reasonable and needed, in fact illumos needs the distribution that is described in here, but I don’t know how to achieve that. As @apg said this is just another fragmentation of already small and fragmented community.
SmartOS being the biggest fish in the tank, being backed and developed by Joyent is probably the best option, but it is not kind of general-purpose-developer Operating System. I have played with illumos, looked at it source code, and no doubt it is the best operating system I have seen (yes I am very young, millennial, and I don’t like linux), but as of now I see FreeBSD to be the best option.
I would really like small, efficient and nifty operating system, that goes somewhere in between FreeBSD and OpenBSD but in illumos land. :)
edit: typos
That’s kind of the goal. I personally lean toward FreeBSD on that spectrum, but one of the other Unleashed devs is a big fan of OpenBSD so he brings that point of view to the project.
(Preface: I didn’t know much, and still don’t, about the *Solaris ecosystem.)
So it seems like the evolution of *Solaris took an approach closer to Linux? Where there’s a core chunk of the OS (kernel and core build toolchain?) that is maintained as its own project. Then there’s distributions built on top of illumos (or unleashed) that make them ready-to-use for endusers?
For some reason, I had assumed it was closer to the *BSD model where illumos is largely equivalent to something like FreeBSD.
If I wanted to play with a desktop-ready distribution, what’s my best bet? SmartOS appears very server oriented - unsurprising given *Solaris was really make more in-roads there in recent years. OpenIndiana?
If Linux (kernel only) and BSD (whole OS) are the extremes of the scale, illumos is somewhere in the middle. It is a lot more than just a kernel, but it lacks some things to even build itself. It relies on the distros to provide those bits.
Historically, since Solaris was maintained by one corporation with lots of release engineering resources and many teams working on subsets of the OS as a whole, it made sense to divide it up into different pieces. The most notable one being the “OS/Net consolidation” which is what morphed into what is now illumos.
Unleashed is still split across more than one repo, but in a way it is closer to the BSD way of doing things rather than the Linux way.
Hope this helps clear things up!
OI would be the easiest one to start with on a desktop. People have gotten Xorg running on OmniOS (and even SmartOS), but it’s extra work vs. just having it.
Solaris is like BSD in that it includes the kernel + user space. In Linux, Linux is just the kernel and the distros define user space.
So…. is there no desktop version of Illumos I can download? Why does their “get illumos” page point me at a bunch of distributions?
Genuine questions - I’m just not sure where to start if I want to play with illumos.
illumos itself doesn’t have an actual release. You’re expected to use one of its distributions as far as I can tell, which should arguably be called “derivatives” instead. OpenIndiana seems to be the main desktop version.
I don’t know. I know there are some people who run SmartOS on their desktop, but I get the feeling it’s not targeting that use case, or at least there isn’t a lot of work going into supporting it.