-
I wouldn’t contribute to Commons Clause projects since they are not inbound=outbound, but it seems they don’t expect contributions anyway. So it is probably okay.
-
I think that’s a completely reasonable response. Many folks won’t contribute to a given project based on the license.
-
-
Redis is an example of this paradigm. Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them.
This makes no sense. Redis was not developped by Redis Labs either, they only hired Antirez a few years ago. Before that, they were doing exactly what they criticize today. I would even say they weren’t the best actor in that space, e.g. OpenRedis was founded by people truly involved in the community…
I won’t say any more before I see a direct take from Salvatore on this issue.
In any case, commercially, I think this is a huge mistake. If they persist Redis is going to be forked and the fork will eventually win, a la MariaDB.
EDIT: I had misread the announcement, this is only about modules which will be Apache 2 + Commons Clause, while the Redis core will remain BSD. I am fine with that even though I think AGPL would make more sense if you want those modules to become popular. Enforcing a monopoly on hosting is never a good idea.
From various comments I can read online it looks like I was not the only one to misunderstand. That Redis was unaffected should probably have been the first line of that post, in bold…
EDIT 2: Salvatore himself is tweeting about the issue on Twitter right now. https://twitter.com/antirez/status/1032192722755571714
-
MariaDB isn’t the bastion of open source people make it out to be.
Since the original claim that a) Oracle would close-source MySQL, and/or let it stagnate to force adoption of their commercial offerings, and thus b) MariaDB would fork MySQL and maintain feature parity, in an open source model:
- Oracle have released several new versions, with major new features/functionality/SQL compatibility
- Oracle have maintained the existing Open Source licence
- MariaDB have broken compatibility in numerous places
- MariaDB have backflipped and made one of their components for running a HA cluster, closed source.
Honestly if your (the reader, not @catwell) app/company needs MySQL and isn’t paying for a commercial licence from Oracle, IMO you’d be stupid not to use either Persona Server or Percona Cluster. Actual feature parity (i.e. they constantly rebase from upstream) and a clear business model: pay for support/advice, the software is completely free.
-
clear business model: pay for support/advice, the software is completely free.
That business model is what Redis Labs is trying to address. There’s a serious problem for companies with that model if a large hosting provider like AWS that more and more people are moving to can come in and offer a “as a service” version that cuts off the support revenue stream. At that point, AWS can benefit from the work that said company is doing without contributing anything back.
Open source software in general and open source business models often assume that you won’t have parasitic players in the market who derive value from the work of others but contribute nothing in return. The current system is going to have to change eventually to account for that.
It might end up being that all open source software is produced by companies that aren’t “product” companies. For example, Google spinning out K8S and not attempting to make money off the software. LinkedIn getting an advantage out of opening up Kafka etc. In that world, eventually, there will be very few companies like RedisLabs, CockroachDB, InfluxDB etc that are trying to be product companies. The large move “to the cloud” that is underway is a huge disruption to that previously OSS business model. I think a model that many will try will be to take an open source product and provide close sourced, additional functionality around those codebases (thereby sidestepping licenses like the AGPL) and doing managed hosting and as a service hosting within the big clouds like AWS, GCP, and Azure.
-
There’s a serious problem for companies with that model if a large hosting provider like AWS that more and more people are moving to can come in and offer a “as a service” version that cuts off the support revenue stream.
Percona provide support services for customers who use AWS’ various mysql flavoured “DB as a Service” offerings.
This is not that different IMO than what Rackspace did - they took their Ops/Arch experience, and offered it as a service, regardless of who hosts the underlying machines.
-
-
-
Re: AGPL
The 3 modules that were reliscened were previously AGPL. AGPL doesn’t provide the protections that Redis Labs is seeking. Most OSS companies have a business model that revolves around support. If a large hosting provider like Amazon comes in and provides an “as a service” version, that cuts off a primary revenue stream. If said hosting provider doesn’t produce improvements to the codebase then AGPL doesn’t matter.
-
-
AWESOME!
I own 2 BeBoxes. Was a Be developer back in the day. BeOS was my primary home OS for about 7 years and primary work OS for a couple years.
I’ve been tracking Haiku for a long time. Looking forward to giving the beta a spin.
-
Wow. I have to reply just so I can say I spoke to a real Be developer. I was too poor to have ever had a BeBox (though I dreamed), but BeOS on Intel was my primary OS for years (somewhat prior to that it was the Amiga; I only pick winners…)
-
Back when I received my BeBox (which is by now in storage in the attic), I was still a student, and switched regularly between BeOS, Solaris and Linux; the BeBox was the best of the devices available to me at that time, and I still have extremely fond memories of it. The intel port of BeOS was great to play with as well, but at that point with my use cases and the demise of Be inc Linux made a much more reliable bet for a daily driver. Pity, as BeOS really was much nicer…
I really should try out Haiku. It might make me even more nostalgic. :)
-
-
-
Resting.
-
I’m hosting my first TLA+ workshop this week. Beyond excited and beyond nervous.
-
-
Kick ass!
-
-
-
-
My personal one is https://www.monkeysnatchbanana.com/ but I rarely post there. Much more of my time goes into stuff on the blog where I work https://blog.wallaroolabs.com/ and for the programming language that I work on https://www.ponylang.org/blog/.
-
Bad idea, it should error or give NaN.
1/0 = 0 is mathematically sound
It’s not mathematically sound.
a/b = c should be equivalent to a = c*b
this fails with 1/0 = 0 because 1 is not equal to 0*0.
Edit: I was wrong, it is mathematically sound. You can define x/0 = f(x) any function of x at all. All the field axioms still hold because they all have preconditions that ensure you never look at the result of division by zero.
There is a subtlety because some people say (X) and others say (Y)
-
(X) a/b = c should be equivalent to a = c*b when the LHS is well defined
-
(Y) a/b = c should be equivalent to a = c*b when b is nonzero
If you have (X) definition in mind it becomes unsound, if you are more formal and use definition (Y) then it stays sound.
It seems like a very bad idea to make division well defined but the expected algebra rules not apply to it. This is the whole reason we leave it undefined or make it an error. There isn’t any value you can give it that makes algebra work with it.
It will not help programmers to have their programs continue on unaware of a mistake, working on with corrupt values.
-
-
-
-
It will not help programmers to have their programs continue on unaware of a mistake, working on with corrupt values
That was my initial reaction too. But I don’t think Pony’s intended use case is numerical analysis; it’s for highly parallel low-latency systems, where there are other (bigger?) concerns to address. They wanted to have no runtime exceptions, so this is part of that design tradeoff. Anyway, nothing prevents the programmer from checking for zero denominators and handling them as needed. If you squint a little, it’s perhaps not that different from the various conventions on truthy/falsey values that exist in most languages, and we’ve managed to accommodate to those.
-
-
1/0 is integer math. NaN is available for floating point math not integer math.
-
It will not help programmers to have their programs continue on unaware of a mistake, working on with corrupt values.
I wonder if someone making a linear math library for Pony already faced this. There are many operations that might divide by zero, and you will want to let the user know if they divided by zero.
-
It’s easy for a Pony user to create their own integer division operation that will be partial. Additionally, a “partial division for integers” operator has been been in the works for a while and will land soon. Its part of operators that will also error if you have integer overflow or underflow. Those will be
+?,/?,*?,-?.https://playground.ponylang.org/?gist=834f46a58244e981473c0677643c52ff
-
-
-
I am a maths researcher at the university of Cologne and adressed this in a thesis I wrote in 2016. See chapter 3, especially the first part of section 3.1.
Dividing by zero is totally well defined for the projectively extended real numbers (only one unsigned infinity inf) but the argument for the usual extended real numbers (+-inf) not working is not based on field theory, but of infinitisemal nature, given you can approach a zero-division both from below and above and get either +inf or-inf equally likely.
Defining 1/0=0 not only breaks this infinitiseminal form, it‘s also radically counterintuïtive given how the values behave when you approach the division from small numbers, e.g. 1/10, 1/1, 1/0.1, 1/0.001…
lim x->0 1/x = 0 makes no sense and is wrong in terms of limits.
See the thesis where I proved a/0=inf to be well-defined for a!=0.
tl;dr: There‘s more to this than satisfying the field conditions. If you redefine division, this has consequences on higher levels, in this case most prominently in infinitisemal analysis.
-
I used to be a maths researcher, and would just like to point out that some of the people who define division by zero to mean infinity do it because they’re more interested in the geometric properties of the spaces that functions are defined on than the functions themselves. This is the reason for the Riemann sphere in complex analysis, where geometers really like compact spaces more than noncompact ones, so they’re fine with throwing away the field property of the complex numbers. The moment any of them need to compute things, however, they pick local coordinates where division by zero doesn’t happen and use the normal tools of analysis.
-
Thanks for laying this out and pointing out the issue with +/- Inf
Could you summarize here why +Inf is a good choice. As a practical man I approach this from the limit standpoint - usually when I end up with a situation like this it’s because the correct answer is +/- Inf and it depends on the context which one it should be. Here context means on which side of zero was my history of the denominator.
The issue is that the function 1/x has a discontinuity at 0. I was taught that this means 1/0 is “undefined”. IMO in code this means throw an exception.
In practical terms I end up adding a tiny number to the denominator (e.g. 1e-10) and continuing, but that implicitly means I’m biased to the positive side of line.
I think Pony’s approach is flat out wrong.
-
It is not +inf, but inf. For the projectively extended real numbers, we only extend the set with one infinite element which has no sign. Take a look at page 18 of the thesis which includes an illustration of this. Rather than having a number line we have a number circle.
Dividing by zero, the direction we approach the denominator does not matter, even if we oscillate around zero, given it all ends up in one single point of infinity. We really don’t limit ourselves here with hat as we can express a limit to +inf or -inf in the traditional real number extension by the direction from which we approach inf in the projectively extended real numbers (see remark 3.5 on page 19).
1/x is discontinuous at 0, this is true, but we can always look at limits. :) I am also a practical man and hope this relatively formal way I used to describe it did not distract from the relatively simple idea behind this.
Pony’s approach is reasonable within field theory, but it’s not really useful when almost the entire analytical building on top of it collapses on your head. NaN was invented for a reason and given the IEEE floating-point numbers use the traditional +-inf extension, they should just return the indeterminate form on division by zero in Pony.
-
NaN only exists for floating point, not integers. If you want to use NaN or something like it for integers, you will need to box all integer numbers and take a large performance hit.
-
-
-
-
-
-
For those wanting the rationale, this is in the same Pony article:
“From a practical perspective, having division as a partial function is awful. You end up with code littered with trys attempting to deal with the possibility of division by zero. Even if you had asserted that your denominator was not zero, you’d still need to protect against divide by zero because, at this time, the compiler can’t detect that value dependent typing. So, as of right now (ponyc v0.2), divide by zero in Pony does not result in error but rather 0.”
-
I’m going to be (when I have time) writing a longer and more detailed discussion of the issue.
-
Im sure many of us would find it interesting. I have a total, mental block on divide by zero given it’s always a bug in my field. This thread is refreshingly different. :)
-
I’ll post it on lobste.rs when its done and I’ve had several people review and give feedback.
-
Thanks!
-
-
-
-
-
-
-
A couple of notes:
-
I when I have more time (work is very busy) will be writing up the rational and features etc that lead Pony to the place that a decision like this had to be made. No one on the Pony team liked ending up there. But fortunately we are a 1.0 language and can continue to evolve and change things. We also thought it was very important to call to call out the issue because it is surprising.
-
It’s easy for a Pony user to create their own integer division operation that will be partial. Additionally, a “partial division for integers” operator has been been in the works for a while and will land soon. Its part of operators that will also error if you have integer overflow or underflow. Those will be
+?,/?,*?,-?.
https://playground.ponylang.org/?gist=834f46a58244e981473c0677643c52ff
-
-
@SeanTallen, glad to see another milestone. Nice release notes!
-
Thanks @msingle.
Was a team effort across the board, including the release notes.
-
-
There is no technical content in that post :(
-
-
Personally, I found the post interesting.
-
-
This is political, and as much as we might like to pretend otherwise, all technology is inherently political.
I dislike this justification being used to shoehorn politics into spaces which previously had functioned somewhat as a refuge from the sturm und drang of the times. I’ve also never seen a good stacktrace for the sentiment.
-
-
Lots of things are interesting but have better homes elsewhere.
-
-
-
-
SeanTAllen
1 month ago
|
link
| on:
Antergos: The first Linux distribution with ZFS support during installation [2016]
This is two years old. Seems like a rather odd submission given how the content is very much of a time period and to my eye, provides minimal value now.
-
I’d never heard of this operating system, and it has never been submitted to Lobsters before.
-
Then why not submit the operating system itself, not some dated “first linux distribution with ZFS” content that is outdated.
-
-
-
-
-
-
I don’t get it, is this something that only matters for OOPy languages? Kind of Design Patternish, isn’t it? That book always struck me as trying to patch Java.
I mean, I understand you could emulate what they’re talking about in languages other than Java and C#, but… huh? Do we really need to avoid if blocks that badly?
-
I’ve done the same sort of thing in Scheme (and other non “OO” languages) in the past. Rather than an if block, use polymorphic functions that are supplied. It takes a little getting used to for the reader but the testability of the code is much higher. I’ve also done the same thing in other languages using various forms of type-level programming.
-
-
The architecture of open source applications should be real-world enough
-
I don’t know is AOSA is what @hwayne is looking for, but for anyone reading, its a great series of books and I’d advise everyone to check them out.
-
-
I’m often amused to remember that there are developers who want “bleeding edge” and rolling release and consider that to be “developer friendly”.
What I want more than anything else is to have my computer work the same day-to-day without fear of it breaking. When I do an update, I want to be to easy rollback if something breaks. When I do an update, I want it update the smallest possible number of components to get the change that I needed.
I’d be far more appreciative of articles like this if it was “why I like Arch” rather than “its developer friendly”. Its not “developer friendly”, its “you friendly”. I used Arch for a bit. Its a nightmare for someone like me, and… I’m a developer. That’s fine though. I don’t use it. For my Linux systems, I prefer point releases + long term support.
-
I’m a developer too. At my workplace, the Arch users just upgrade their packages, and have a stable system for a decade, with a small risk of having to configure or force-install a package every N years. The Ubuntu/Mint people do a distro-upgrade or reinstall the system every N years.
I’m not sure which is worse, but there is more cursing and complaints from the Ubuntu/Mint camp.
-
Maybe it’s just me (I like occasionally hacking on drivers and such), but I consider “developer friendly OS” to mean “friendly to developing the OS itself” (which is why I run FreeBSD -CURRENT).
Developing apps is not that special and doesn’t require much “friendliness”, IMO. Just having not-ancient versions of all common libraries/runtimes/etc. is enough.
That said, mainstream Linux distros like Debian/Ubuntu/Fedora do have an “unfriendliness” in terms of splitting headers into separate
-dev/-develpackages. What are they trying to do, save 10kb of disk space per shared library?! Artificially inflate package counts? This is infuriating: “What do you MEAN pkg-config can’t find this lib– OH DAMMIT I need the dev package! What, why is libwhatever-dev not found, oh I need to search because it’s called whatever01despacito-dev-69420.0.0002 WHO EVER THOUGHT THIS IS A GOOD IDEA” -
I haven’t used Arch but I have the same intuition. I run debian stable on my desktop and servers and have very rarely found myself wanting anything more cutting edge.
-
-
“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.
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.
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)!
-
Thanks for taking the time to respond.
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)!
Thanks, that’s the idea :)
-
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.
-
There’s really nothing I can offer as a legitimate excuse for that. I’m sorry.
No worries. Hopefully my initial response didn’t come across as too harsh either. If it did, my apologies.
I am against forks that don’t offer some radical divergence in philosophy, though.
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.
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.
-
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.
-
Why do I need to understand the culture of a tool I use?
Some example of the issues you might face:
- an security update could be delayed
- an update upstream could break your work in production
- you (or one of your customers) could be sued for patent violation (even if you are not actually violating it)
- the project might contain backdoors and your image could be associated with it
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.
-
Some example of the issues you might face…
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.
-
There are ways around much of these concerns.
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.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.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.
-
-
-
-
I’m sorry about this.
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.
-
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.you may be shortsighted in your assumptions.
I woudn’t even engage if I woud not assume this to be possible: there would be nothing to learn.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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!
- 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.
Hopefully I covered everything.
-
-
-
-
This blog post: a case study in being a jerk to someone who is being a jerk, only since Linus is a “jerk” you get off scott-free. Unsurprisingly, this is written by someone who has never contributed to the Linux kernel and who was uninvolved in the discussion he’s picking apart.
The revised email at the end does lose information. Contrary to what hipsters write blog posts complaining about, 99% of Linus’s emails are cordial. The information that’s lost is the conveyance that this is more important to Linus than most subjects.
-
This comment: a case study in being a jerk to someone who is being a jerk to a jerk.
In all seriousness, I don’t believe that Gary Bernhardt is being a jerk at all. There’s a line between being critical of a piece of work and calling someone brain damaged, and hopefully, we all can see the difference.
Aside: I love when people use the word “hipster” to invalidate other viewpoints. Apparently, there are two modes of being: Being Right and Being A Hipster.
-
To the unserious comment, I don’t think I was being a jerk. I called him a jerk, which I guess you could argue is a jerk move under any circumstances, but if I’m being a jerk then so is Gary.
To the serious comment, I just want to note that “brain damaged” is a meme among old school hackers which isn’t as strong of a word as you think.
To the aside, I don’t use hipster as an insult or to imply wrongness, but I do use it to invalidate his point. Gary is a Ruby developer. Linus is a kernel developer. The worlds are far removed from each other.
-
I’ve put tens of thousands of lines of C into production, including multiple Linux kernel drivers. In one case, those kernel drivers were critical-path code on a device used in strain testing the wings of an airplane that you might’ve flown in by now.
I’m not a stranger to the kernel; I just left that world. Behavior like Linus’ in that email was part of the reason, though far from the only reason.
With all of that said: having written a bunch of systems software shouldn’t be a prerequisite for suggesting that we avoid attacking people personally when they make programming mistakes, or what we suspect are programming mistakes.
-
Exactly. I’ve also met many people that do high-performance, embedded, and/or safety-critical code in C that are more polite in these situations. Linus’ attitude is a separate issue from what’s necessary to evaluate and constructively criticize code.
-
-
“brain damaged” is a meme among old school hackers which isn’t as strong of a word as you think.
Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.
I don’t use hipster as an insult or to imply wrongness, but I do use it to invalidate his point. Gary is a Ruby developer. Linus is a kernel developer. The worlds are far removed from each other.
Gotcha. Kernal developer == real old-school hacker. Ruby developer == script kiddie hipster. Are we really still having this argument in 2018?
-
Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.
“Brain damaged” is a term from back in the Multics days, Linus didn’t make that one up for the occasion. If you’re unfamiliar with the “jargon file” aka hacker dictionary, you can see the history of this particular term here: http://www.catb.org/jargon/html/B/brain-damaged.html
-
Yikes. That “meme” is a whole other thing I don’t even care to unpack right now.
Listen, cultures are different and culture shock is a thing. I’m in a thread full of foreigners shocked that customs are different elsewhere. You better just take my word for it on “brain damaged” because you clearly aren’t a member of this culture and don’t know what you’re talking about.
Gotcha. Kernal developer == real old-school hacker. Ruby developer == script kiddie hipster. Are we really still having this argument in 2018?
How about you quit putting words in my mouth? Do you really need me to explain the world of difference between Ruby development and kernel hacking? In 2018? It’s not a matter of skill. Gary is great at what he does, but it has almost nothing to do with what Linus does. The people who surround Gary and the people who surround Linus are mutually exclusive groups with different cultural norms.
-
You can’t use “it’s our culture” as a panacea; calling someone an idiot, moron etc. is a deliberate attempt to hurt them. I guess if what you’re saying is, “it’s our culture to intentionally hurt the feelings of people who have bad ideas,” well, then we might be at an impasse.
-
The kind of toxic exclusivity and “old school hacker culture” elitism that you’re spouting in this thread is not what I expect to see on Lobsters. It makes me genuinely sad to see somebody saying these things and it also makes me apprehensive of ever being involved in the same project or community as you. Software development today is not what it was 20 –or even 5– years ago. Today it is far more about people than it is about software or technology. You may not like this, but it is the reality.
-
-
“old school hacker culture” elitism
Near 40, I can agree to be called old. But not elitist.
And I cannot accept to be associated with racist.Not all software developers are hackers. Not all hackers are software developers.
Is stating this “elitism”? Is it “racism”? Is it being “jerk”?
Or is just using terms properly?
-
-
-
-
-
-
-
The information that’s lost is the conveyance that this is more important to Linus than most subjects.
So add “I want to stress that this issue is really important to me” at the end of the revised email.
I think that making an issue out of this particular information being lost is missing the point - that it would be possible to say the same thing as Linus did without being abusive.
Contrary to what hipsters write blog posts complaining about
You’re falling into the same trap that the post discusses. This derision isn’t necessary to make your point, and doesn’t make it any stronger - it just adds an unnecessary insult.
-
-
(I am not defending Linus’ behaviour here, please don’t put those words in my mouth.)
I strongly take issue with American ideas of “professionalism”, and an even more so with the idea that we get to decide whether this project is “a professional setting” or not. What exactly makes this a “professional setting”? What is a “professional setting”? Why do we hold some interactions to higher standards than others?
I suspect “money changing hands” is the thing that makes this “a professional setting”, and that grinds my gears even further. Why are we supposed to hold ourselves to different standards just because some people are getting paid for doing it?
-
-
The Linux kernel is not a professional setting. Besides, I argue that the 1% is useful, even in a professional setting - sometimes strong words are called for. I’ll be That Guy and say that people should grow a thicker skin, especially people who weren’t even the subject of the email and have never been involved in kernel development.
-
If I look at who the contributors to the Linux kernel are, it would certainly appear to be a professional endeavor.
A large chunk of contributions to the kernel are made by people who are getting paid by the companies they work for to contribute. Sounds like a professional setting to me.
-
Linux development is only “a professional endeavour” (which is a phrase I have strong issues with, see above) because some people decided to build their businesses in Linus’ craft room. We can like or dislike Linus’ behaviour, but we don’t get to ascribe “professionalism” or lack thereof (if there even is such a thing) to Linus’ work or behaviour, or that of any of the contributors.
Even if “professionalism” is an actual thing (it’s not; it’s just a tool used by people in power to keep others down) it’s between the people doing the paying, and the people getting the pay, and has nothing to do with any of us.
This idea that people should behave differently when there’s money involved is completely offensive to me.
-
-
So, having a hobbyist involved means that you can be dickhead? Is that the conclusion that should be drawn from your statements?
-
-
“I’m saying that Linus is not a dickhead”
His comments are proving otherwise given the main article shows the same information could’ve been conveyed without all the profanity, personal insults, and so on. He must be adding that fluff because he enjoys it or has self-control issues. He’s intentionally or accidentally a dick. I say that as a satirist whose a dick to people that give me headaches in real life. Although it doesn’t take one to know one, being someone whose always countering dicks and assholes with some dickish habits of his own makes what Linus is doing more evident. If no mental illness, there’s little excuse past him not giving a shit.
-
-
Im identifying the cultural norm of being an asshole, saying it applies to him at times, and saying the project would benefit if he knocked if off. Im not forcing my norms on anyone.
Your comment is more amusing giving someone with Linus’s norns might just reply with profanity and personsl insults. Then, you might be complaining about that. ;)
-
Then, you might be complaining about that. ;)
No, I’d just accept that people from different cultures behave differently.
Let’s face it, most people hate getting told they are wrong, regardless of the tone. That’s just how we are as humans.
Taking offense about the tone just seems very US-specific, as they are accustomed to receiving some special superpowers in a discussion by uttering “I’m offended”.
Some of the best feedback I received in my life wouldn’t be considered acceptable by US standards and I simply don’t care – I just appreciate the fact that someone took his time to spell out the technical problems.
Here is a recent example: https://github.com/rust-lang/cargo/pull/5183#issuecomment-381449546
-
Here is a recent example: https://github.com/rust-lang/cargo/pull/5183#issuecomment-381449546
I’m not familiar with Rust, so maybe I’m missing crucial context, but I read this feedback as firm but unproblematic overall. Compared to Linus’ email:
- Comment admits that there are multiple points of view, gives case for their take on it.
- Focuses on the problems at hand rather than speculating on characteristics of any individuals involved, beyond acknowledging other viewpoints.
- Doesn’t include any personal insults.
- Doesn’t include any profanity that I noticed, certainly not gratuituous profanity.
It could be nicer, sure. But it seemed respectful, in the “you can do what you’re doing but consider these things:” kind of way…? The author event went out of their way to acknowledge being unconstructive.
To my reading it seemed closer to Gary’s email than Linus’.
To put it another way: if Linus wrote emails like this (only shorter, probably) then I don’t think Gary would have written a blog post about it.
(For the record: I’m not American, but I do fall on the gee-it’d-be-great-if-Linus-stopped-abusing-his-colleagues side of this debate.)
-
I didn’t intend to imply that this was comparable to Linus’ mail, but that people who would be offended by Linus’ writing would also be offended by that comment.
It’s a slippery slide where every honest-to-go comment that expresses real feelings starts getting replaced by “this is an interesting idea, but did you consider …” corporate lingo, even if the code is horribly wrong.
-
I didn’t intend to imply that this was comparable to Linus’ mail, but that people who would be offended by Linus’ writing would also be offended by that comment.
I understand this is your point, but I think there is no evidence for this. The people complaining about Linus’ conduct are complaining about specific things, and these things are not present in the comment you linked.
Did anyone in the Rust community (generally considered a “nicer” community than kernel development) raise concerns about this comment?
There is a difference between “not overtly nice” and “openly abusive”, even accounting for cultural context.
-
-
Then you and I arent that different in how we look at stuff. Ive just layered on top of it a push for project owners to do what’s most effective on social side.
-
-
-
-
-
-
These numbers suggest it is a professional endeavor:
-
-
-
-
-
-
Linus himself is working in a professional capacity. He’s employed by the Linux Foundation to work on Linux. The fact he is employed to work on an open source project that he founded doesn’t make that situation non-professional.
-
-
-
-
The lack of anything meaningful in this content is really concerning. Especially as it managed to make the front page on more than 1 site.
Imho this sounds like what is potentially/usually addressed by the AGPL.
No, the text they write definitely shows that they are in for the money.
AGPL can be used like that… cannot it?
It doesn’t address the core problem. Most OSS companies have a business model that revolves around support. If a large hosting provider like Amazon comes in and provides an “as a service” version, that cuts off a primary revenue stream. If said hosting provider doesn’t produce improvements to the codebase then AGPL doesn’t matter.
I thought AGPL is specially forged to prevent that. Or do you mean that Amazon recreated their own version from scratch?
AGPL says you have to release improvements. It doesn’t make you contribute to the community.
If a community is getting a lot of financial support from a company like Redis Labs paying for core open source work, a company like Amazon can come along and do an as a service version and contribute nothing. AGPL does nothing for that.
The issue is many projects are pushed forward by commercial offerings that rely on support/services as a means to provide financial support. Our open source licenses provide no protection for that model.
Perhaps the model is flawed and we need something better. But there is no protection from parasitic behavior in that case.
It extends further though, in general, there’s no way for an open source community to develop a means to financially support itself and not rely on free labor that is free of concerns. But that’s another topic.
The world has changed around free and open source. They haven’t adjusted to that change beyond AGPL being created to address some issues.
I personally don’t think that commons clause is the right solution but I understand the problem they are looking to solve.
Apologies for any typos. I answered this from my phone.
Nice explanation!
Companies dual-license under both GPL and AGPL. So, it could be done AGPL with cloud vendors paying a license. There’s a lot of FOSS developers that oppose the AGPL, though.
The previous license for the 3 modules in question was previously AGPL.
It absolutely is. Read the FAQ section on the AGPL, it’s very unclear. ‘Many features of the AGPL…’ kind of language. What features? It’s not the Linux kernel, it’s a license, it’s pretty small, just say what these supposed features are.
Of course the reason they don’t is that it’s a smokescreen: the AGPL is of course fine, but their goal isn’t to make the software free, it’s to profiteer off it.
Yes, Redis Labs is in the business of paying people to work on Redis and the Redis ecosystem and needs to make money to do that. The business model for companies such as that is based on support. If someone cuts off that revenue stream the money falls apart. We can as a community accept that such companies will need to build protections for themselves (licenses like common cause or having some closed source components) or accept a world in which there are no companies that exist to support specific products that could be turned into as “as a service” by a large player.
The AGPL does nothing to stop someone like AWS from taking what Redis Labs does and making money off of it and wrecking the Redis Labs business model (which is shared by a number of companies). I commend them for trying an approach that leaves the module source available and even “open” for some segment of the user base. The alternatives are “new business model”, “go out of business”, or starting to make more and more of their offerings closed source.
Nonsense. AWS wouldn’t touch an AGPL redis with a ten foot barge pole.
AGPL/commercial dual licensing is actually open source.
Calling this open is literally telling a lie.