Posts by Phil Lord 103 posts • joined 22 Jul 2011
Locking the PR involves the impact of having to delete all the daft comments of the form that we have sen here. If it is a feel-good crusade, well, that's fine. It has made something a little bit better if people are feeling good.
A PR stunt to self-promote? They just made a change. Lots of other people are doing all the self-promotion for them.
I think that would be a good argument if we didn't continually the words we use because we are industry where fashionable buzzwords are part of our meat and drink.
I mean this happens all the time, so really changing "slave" to "dependent" is really going to get lost in the noise.
Here is the justification.
It is a small change, which simply moves one name for another. It took them no time at all, because they were sensible enough to lock the pull request before a bunch of right wing nutjobs descended it. The change means that one of the more unpleasant parts of human history will no longer be used as a metaphor for a piece of computing.
So a low impact change; won't make things a lot better, won't make anything worse.
Really. It looks to me like you are saying that because someone has made a small and technically inconsequential change to their project on the basis of it reflecting in a mood change in society, you are not going to use their software. At the same time, you are saying that the maintainers lack technical focus. Even though you are prepared to make a decision without any reference to the technology at all.
Makes no sense at all. Why don't you just drop the facade of "technical focus" and say "I will not use a piece of software whose maintainers make political decisions I disagree with". You'd have my vote on the underlying principal there, regardless of whether I agreed or disagreed with your politics.
What does Rust do?
Well, it provides a clean, high-level language which is comfortable to use, while providing a single powerful language feature that makes a very large class of bugs extremely unlikely in normal use (ie double free, buffer overflow, uninitialized memory, and memory leak).
It does not have garbage collection any more; it did at one point, but it now uses "lifetimes" to be able to work out when it should automatically free things without the programmer having to do anything. Looked at another way, it has a static analysis garbage collector -- so like a Java style GC without the runtime overhead. For when that isn't enough, it has reference counting, but used only for those bits of code that need it. No application needs GC; they need automated memory management, and Rust has that.
How does it do "hard stuff" like Linked Lists with pointers. It uses pointers. The safety guarantee is, as I say, just a language tool. Most of the time you use this tool, and that's fine, but you can write "unsafe blocks" which let you outside the box, which includes raw pointers, even pointer arithmetic.
If someone hacks rustup.rs, then could put anything they like up there and people would run it now? On the other hand, if someone hacks an .deb, or RPM server, they could put random binaries up there, but they couldn't sign them.
It's not, perhaps, ideal, although as it's non-root, it's a little less of a disaster.
Trait implementations have overhead if you cannot determine what the trait implementation is at runtime -- you end up with a virtual method call. However, if you use traits as a generic bound, you can work out the implementation at compile time, so no over head. Array bounds checking, yes, also, although if you iterators like the `for` loop does, it does not array bounds check. For some uses of arrays in C, Rust uses tuples which again do not bounds check (at runtime -- they are type safe at compile time). Memory dropping is worked out at compile time in most cases. You can explicitly use reference counting where it's too complex to work out where dropping should occur at other times and yes, this has some overhead.
Finally, all of this you can turn on with unsafe code. And, of course, all of the above is true on the Rust side; in practice even when Rust thinks it is array-bound checking, LLVM may be optimizing it away.
What I am saying here is not that Rust is faster or that C is faster. I am saying that you cannot reason it; you have to build it and check.
Rust does very few runtime checks -- the majority are done at compile time, and the runtime ones are normally explicit at development time (that is, you know you will be getting a runtime check). In all cases, if you *really* care about performance you can run time checks and do most of the things you can do in C, sacrificing the safety guarantees in those areas.
I would also say that Rust has fewer undefined behaviours than C, so the Rust one can optimize to run faster than the C one. Of course, it might not, but I think the idea that C is going to be faster is not true.
This doesn't install rust, it installs rustup which installs rust. Everything else is underneath that. You can install it in other ways if you like, but this approach is nice because it's non-root and updated at the same time as Rust is.
Most installation processes require you give over all power on your computer to the installation process. This is as safe or unsafe as your trust in the organisation at the other end.
Although, actually, the Rust installation suggested above is probably less dangerous than many since it does not require admin access.
`let` has been around for ages in functional languages. Obviously having a keyword there means that you cannot do:
let my_variable = 1
me_variable = my_variable + 1
or similar spelling mistakes. Unintialized variables are fairly rare in Rust. If you want to, though, you can do it, but it still produces something that is vaguely readable because you need the type:
let s: String;
Yes, "var" and "const" are contractions of words, but Rust emphases "const" -- so "let" on it's own is equivalent to "const". To get `var` you do `let mut x = 1`; a bit wordy, but the `mut` keyword is also uses in locations other than `let` declarations, such as parameters for instance.
It all makes sense, I think and was thought out.
The Rust library ecosystem is a little biased toward the systems programming end, but it's actually a pretty rich environment overall, and because the tools (esp cargo) are good, it's easy and low cost to add dependencies to your own projects. There have been significant efforts to cover the few remain holes that exist.
Having said that, my own experience is that it can be hard to find a the right library out of several choices, and the rust community has got a bit obsessed with semantic versioning, meaning that libraries tend to sit at version < 1 for ages; bit like googles tendency to call everything beta.
Oh, that's easy. It is all achieved at compile time. So, *efficiency* in the runtime sense of the word is not affected at all. The "portability" bit largely comes from LLVM which Rust uses to produce the final binaries. Or to look at it another way, Rust achieves memory management through it's type system.
The compilation process is a little bit slow, though, partly because of this checking, although, in practice this time is far outweighted by LLVM doing it's thing, especially when running under full optimisation.
The original poster is also simplifying things somewhat; actually, Rust has a "safe" subset that does all of this. It also has an "unsafe" set -- you lose the guarantees, but can do any memory manipulation that you want, including referencing invalid memory locations. You don't need to do it that often, but the option is there if you need it.
I thought long and hard about Rust or Go, when I was starting a new project that I wanted to be fast.
In the end, I went for Rust; it seems to have fulfilled it's promise to be honest. The code is clean, succinct and even with a naive implementation is more than an order faster than Java equivalent that I wanted to replace (I realise that Java is not a speed monster, here). In terms of usage, the tooling is very nice and comfortable, and the language really gives the impression of being carefully thought out, and as equally carefully developed and updated. Of course, there is only so much time in the world, so how much of this would be true of Go, I cannot say, because I tried it less.
In the end, there were a three main reasons for choosing Rust. First, although it is indeed a fussy language, the community is very supportive and has helped me when ever I needed it (and as probably the first local adopter I needed it). Secondly, it's backed by Mozilla who are, I think, less likely to be evil than google; in particular, there is a strong community ownership of Rust. And, finally, the killer issue, which is reason enough to choose all by itself: Go uses tabs by default; and not just tabs it uses combined tabs and spaces; it is too hideous for words.
(Yes i know this is El Reg, yes i know I'm painting a target on my back)
The Register is not really known as an abode of the left wing. There are a set of people around with those opinions, but they (well, we) hardly overwhelm the place.
In this case, there are a number of issues with the name GIMP -- as well as having alternative definitions that are not good, it's also a big acronym that doesn't suggest the use of the software. Neither of these are particularly sensible from an advertising point of view. Sodipodi died a death for a somewhat related reason (no one could remember it).
I'm a little unconvinced that renaming GIMP is worth the effort, but it is not a good name, nor has it ever been. This is far from being touchy.
Well, given the Scotland pays for the UK government as well, hard to see how that would work.
Besides, if you use that logic, the remnants of the UK would have to give back everything that Scotland paid for. Unfortunately, that would include Margaret Thatcher and 40 years of failed economic policies, so I am not sure that Scotland would want them.
Python 2 and Python 3 were formal "forks" and Python 2 was supported for a long, long time. It is starting to finalize now, though, and Python3 is taking over. JDK8 is not really supported any more, nor did they plan to.
The main problem though was that Oracle let Java get stale and then did a massive release. Bit odd, really.
Yes. Of course. It could all be nonsense. Dark matter could go the way of the luminiforous either or phlogiston. And maybe fiddling with, for example, gravitational attraction equations would solve the problem. And, there are physicists doing that also. And both groups are working hard to develop their theories to the point where they are accurate and descriptive enough that they can be tested.
When the authors say "dark matter does this" and "dark matter behaves like that", they are, I am sure, aware that it might not exist. But, to speak that way all the time produces bad prose. Consider: "gravity attracts objects based on their mass and the square of their distance appart, or more or less although perhaps it's not exactly the square of the distance." It doesn't really work.
"Merit in this case is derived from creating code that meets the requirements of the software"
Determining what the requirements actually are by interacting with users of the code. Being an advocate for any systems that are produced. Training down stream users. Interacting with other stake holders to demonstrate the value of the system. Providing calm and rapid management of the system when it has and outage. Ensuring that any UI (or API) is clean, clear and highly usable. Operating within a regulatory framework. Ensuring that all members of a team can work well with each other. Providing a support environment for incoming contributors.
All of these are relevant to the success of a project. This is why "meritocracy" is a low value term. Everyone can have their own ideas about what merit is. You have told me what your notion of merit is; that's okay but it seems a bit narrow to me. So, we can move beyond this: you are arguing that ability to code is the most or only important contribution to a software project; I am arguing that it is not.
"They're called unit tests."
And how do we write these? And how do we judge the quality of our unit tests?
"we see someone who evidently doesn't understand how software development works."
That's fine. Feel free to dismiss my position if you want. If you really think that "my unit tests are working" is equivalent to "good code", then I will probably not convince you otherwise.
"meritocracy": a society governed by people selected according to merit.
Where "merit" is defined in what way?
"divine right of kings"
Where "merit" is defined as the person most wanted by God.
The circularity in the argument of "meritocracy" happens because we don't have a clear definition for merit. As a result, we can look at most environments and say "well, this environment is very unrepresentative selection of the population, but that's because it's a meritocracy".
"The problem is the sort of person who wants to volunteer for that sort of committee is always the same"
Well, then, it looks like the problem is at least in part the people who do not volunteer.
"so leaves no room for anyone different from themselves"
Could be a problem. And if that happens, we may end up with tech being dominated by a group of people who are extremely poorly representative of the population at large. Who knows where that would lead?
"No, the idea of meritocracy is very simple: it doesn't matter who you are, does your contribution do what it is meant to do with as little cruft and structural weakness as possible? If yes, it passes. If no, go back and do it again."
None of which is objectively measurable -- if it were, we could write a program to measure it. If we could do that, we could replace the programmer with a random code generator. So, all of these things require using judgement.
And, of course, you seem to have the slightly strange idea that only code function counts. What about someone who is capable of producing a clear and coherent API? With great documentation? Or someone with the vision to understand that you had the wrong idea about "what it is meant to do" all along and that really, you should do something else.
Developing a good piece of software is not just programming, any more than programming is typing.
"There is no such thing as 'poor code' in the post-meritocracy world."
The idea behind the "post-meritocracy" is that we should get passed the point where we can use spurious or ill-defined notions of "merit" to justify what ever kind of injustice or nastiness we want.
The way that "meritocracy" is used is pretty close to the "divine right of kings". Good code, bad code, of course, still exists. I write both, and sometimes unable to distinguish between the two. That makes me pretty normal I guess.
"As defined by whom?"
Normally a committee, consisting of a number of members of the community. It a similar process that would apply to censure of a developer who routinely submitted poor documentation for their work. Or, indeed, poor code. It's hard to make an objective judgement about either of these things either.
"The definition of undesirable is whoever in power does not want to be around."
Actually, the intention of a CoC is the opposite of this. It's to put forward an explicit definition of what an undesirable is. How successful they are at achieving this, I don't know. If you have any data beyond the anecdotal about this, it would be interesting to see.
"I ask simply this, how many times has it been used like blasphemy accusations in Pakistan, as a lethal weapon?"
Well, the contributor covenant has no clause requiring the use of the death penalty. Even if it did, in most of the jurisdictions in which it is used, this would be considered to be a unfair contract and therefore not enforceable.
So, in simple answer to your question, it's never been used as a lethal weapon.
"It betrays an obsession with feelz and a demand for ideological purity which many people find revolting."
Yes, but then I find lack of politeness pretty irritating also.
"You don't need a CoC to deal with what is illegal."
Yeah, you do. Most organisations have relatively strong policies relating to bullying and harrassment, and a mechanism with dealing with it. And they have to because if they do not they will appear complicit. Look at is this way: child abuse is illegal, but does that really mean that schools do not need to have policies for safeguarding children? Of course, this is not to say that a CoC is needed to cover all potential illegality; there is little point in saying "murdering people will be grounds for removal" because that is just silly.
In the case of Linux, "legal" is made more complex by the multiple jurisdictions that people find themselves in, so being explicit about the project may help.
"It's mostly obsessed with sex, race and gender."
These are legally protected characteristics in many jurisdictions. By definition, any policy about harrassement is going to involve these characteristics.
"Can you express thoughts regarding illegal immigration without falling foul of this?"
That's a good question. The CoC gives you a basis for making a decision on these things, but how they are applied in practice is very important. I would hope that you could express thoughts about illegal immigration even though, I suspect, I wouldn't like those thoughts. Similarly, for instance, while I think discrimination on grounds of religion is a bad thing, I would like to be able to say that most religions make little sense.
If it works badly, indeed, you might be excluded from saying such things. If it works well, then, perhaps linux (and other free software projects, including some I contribute to) will become a politer place to be. I am hoping it goes well.
"That would require getting confirmation from all contributors, including those you can't find and from the executors of those who no longer exist."
It doesn't actually. It requires agreement from the owners of the code which is currently in the kernel. So contributors whose code has been written out over the years are not relevant. And the number of owners is smaller than the number of contributors, since everyone working for RedHat or equivalent counts as one.
'You can and will be judged solely on your code quality' .
This is just silly. There is world of things that sit around code quality that are also important.
For example, you might have good code, but you probably need to be able to write coherent English explaining what the code is for and what it does. So you need to be able to use an email list also. So, you have a social element. Having someone easy to understand is important, of course, but someone who is easy to interact with also is a boon to a project.
Then there are legal issues to be considered. Of course, these are rarely as serious as the issues that Hans Reiser has, but say you have a developer who routinely issues threats of violence or death to others, then this is illegal.
And so it goes. It seems nice and simple, of course, to say "it should be all about the code". But it's simple, it's simplistic. Life is more complex than that. Whether the new CoC is a good solution I don't know. But having something a bit more serious that "be excellent to each other" seems like a good idea.
The idea is that changing language can help to change the debate. And, of course, it has a long history and does work: nowadays the use of the "n-word" on TV is uncommon and always considered offensive; the introduction of the term "gay". There are many examples.
For myself, I find it hard to get excited about "master/slave", simply because in the UK at least it's largely historical. Perhaps, that is a luxury others do not have. One of the things that I do find amusing, though, is all the people who like to spend their time commenting on what a waste of time this is, when we should be coding. And others complaining about the principle of trying to change language to change the debate, and then blaming it all on SJWs and snowflakes: terms invented in an attempt to change the debate.
For example, a religious school can discriminate both their children and staff have a certain religion. For most organisations, this would be illegal as it would breech the equal opportunities legislation; but the churches lobbied and achieved a specific exception in the law, which means that they can do it.
For reference the code of conduct is:
be friendly and patient,
be welcoming,
be considerate,
be respectful,
be careful in the words that you choose and be kind to others, and
when we disagree, try to understand why.
Seems relatively hard to interpret "be friendly and patient" as Draconian.
'Or can we only "positively" discriminate on the "right" stuff?'
Yes. Discrimination on grounds of gender is illegal (in the UK), except under very specific circumstances. One of those circumstances is an extreme standing gender split in a profession. If the bias is not extreme, or starts to disappear, you cannot do it any more.
"When someone says that the way to combat discrimination is WITH discrimination, all I see is a hypocrite."
Positive discrimination is a difficult one. On one hand, it is consistent and simple to say we should not do it because it's discrimination. And that's nice, but simple is not correct. Consider the use of positive discrimination in Northern Ireland, to stop the anti-catholic bias. Consider, the legal alterations for voter registration in 1960s in the US, to overcome an effective anti-black block on voting.
If you think that these things were hypocritical, then that's fine, but they were both effective in ending a violent and coercive status quo.
Is that what we have here? Not sure, but when you have an occupation which is 90% men, you have to ask questions about whether there is an effective block on women.
"Sorry, but you need to think of your safety as your responsibility. If you overtake a truck on the inside, you're going to die."
It's wrong to assume that a cyclist that got hit by a left turner turner went up the inside. A lot of the time, the lorry moves up the outside, then forgets that the cyclist they can no longer see is there, then turns left.
This is especially common at traffic lights where the cyclist can do very little about it. It's the reason why jumping red lights on a left turn is usually safer for a cyclist than obeying the law.
Shockingly, it is possible to cycle in normal clothes, and not shower at the other end, because you don't get sweaty. The reason for this is that most urban journeys are 3miles or less, over which distance a cycle is entire comfortable.
Unfortunately, in many cities, there is no space for cycling, and the experience is miserable of the cars. Provide the space, the number of cyclists go up. The lycra clad, helmeted, cyclists, high-energy lasers for headlights is a product of car-centric city planning. We don't need their numbers to go up. It's everybody else.
"So far as I know there is nothing happening whatsoever, and so Perens statement is for the moment incorrect. And therefore, currently, garbage."
"It’s my strong opinion that your company should avoid the Grsecurity product sold at grsecurity.net because it presents a contributory infringement and breach of contract risk."
Am afraid it is your statement which is garbage. As you can see from the quote, BP suggested that is presents an infringement risk. So, a) his statement is an given as an opinion and b) as a risk. So, not incorrect at all.
If I say, "travelling at 40mph in a 30mph area puts you at risk of a fine" this is true, regardless of whether or not you get stopped.
Cross-fertility is, unfortunately, too simplistic. A great dane and a chihuahua are not cross-fertile, yet are the same species. A horse and a donkey are cross-fertile but are a different species.
There are lots of games that you can play to finesse these definitions of course, but still as an overarching definition for species it doesn't work, because the majority of organisms on the planet are not cross-fertile with anything and reproduce asexually.
Biology is complicated.
Because the cost of policing and administering the insurance would outweight the actually payouts of the insurance. Cyclists cost little infrastructure, and cause very little damage to others. In short, why do you not have insurance for walking around the streets. It's about as dangerous.
We do. It's very old legislation, but it exists and it's comes with extremely significant sentences.
Just to be clear, though, cyclists can cause lethal injuries, but statistically, it's a very small problem. More pedestrains are killed every year by cars mounting the pavement and running into them than my cyclists at all (about 100 to >10).
In fact, it's likely that the dust from car brakes cause more deaths per annum through respiratory disease than cyclists.
In short, nutter cyclists are anti-social. Car drivers kill people in industrial numbers.
Well, we don't know. I would imagine though he is not asking for damages, he is asking for a contract to use his code which in turn means that they can use the rest of linux. If you are using his code (especially indirectly), and someone says you can't do this because I will sue you unless you pay me, then you end up paying.
It doesn't matter how much the code is. Remember, at one point in the Java wars, they were talking about 11 lines of code, and claiming billions.
It discriminates against women because they are generally shorter than man, hence it is effectively a mechanism to discriminate against a protected characteristic -- your gender.
It does not discriminate against short/tall people because that is not a protected characteristic. "Discrimination" in a legal sense does not just mean "distinguish" or "differentiate".
Yes, that covers it. Democracies can change their minds about things, and a later vote trumps an earlier one. Democracy is not about "the people have spoken" (i.e. they HAVE spoken, now they can shut up).
Obviously, the chances of us staying in the EU have been considerably lessened as a result of the referendum, but it isn't a done deal, and there is nothing wrong with trying to find a way to make it not happen. And, if it does happen, there is nothing wrong with trying to find a way to reverse it. Democracy is not a state but a process; its always going on.
"You seem to be under the impression that functional languages have some magic fairy dust they sprinkle on their recursion."
Yes, they do. The magic fairy dust is called bloody necessity. You have to have fast recursion in a functional language or it all goes pair shaped. In an object orientated language, you often don't.
Case in point: the JVM does not implement generalized (nor any) tail recursion. A problem for both Scala and Clojure which are compiled to JVM byte code. Solution: both use a hack in their respective compilers to provide at least a specialised tail recursion that addresses the issue in most cases.
Java could do it, but doesn't. Clojure and Scala do do it, because they have to.
You work out a way to "copy" a list efficiently, so that you can make a new one for every step without it going really slow. It's easy to do this with a singly linked list; you can share identical list tails between all other lists that have the same tail. It's relatively easy to program, although quite hard to visualize, which is a recurrent theme for functional programming.
The other way is to google the answer. Although we are, apparently going through a functional craze at the moment, people have been thinking about this stuff for years. All the simple and obvious questions were answered 20 years ago, so you usually find the answer if you really want it.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020