Posts by Phil Lord 169 publicly visible posts • joined 22 Jul 2011
Rsync and unison are fundamentally different. Unison understands which direction files should be transferred in and when there is a conflict. That requires keeping a history.
Rsync just looks at the status quo. It will do bi-directional sink perfectly well, but if you are not carefully about what you tell it to do, it will either delete data or restore files that you wanted to delete.
The plan was never to port all the emacs-lisp code to guile. The guile VM is multi-language so the idea was to place the Emacs lisp VM with guile. The C layer would get called as it does now just by guile. The big advantage of this is guile is a compiled VM rather than a interpreted (but byte compiled) language like Emacs lisp. So a lot faster, in theory. Although as Emacs now also supports native compilation through a JIT (being used ahead-of-time, if that makes any terminological sense) that is perhaps less of an advantage than in the past.
This runs completely counter to my experience. The rust forums have been extremely helpful, with some folks going to a lot of effort to answer even in depth technical questions.
In fact, they have a strong policy that says "don't tell people to do their homework". The logic is that if you don't want to answer a question, you don't have. Just move on rather than take the time to say it shouldn't have been asked in the first place.
You could build a USB-C with an outer casing that fulfilled the rugged requirements with the actually power going through the USB still. When you didn't need the rugged, you could open the casing manually and still use a normal USB-C connector. Kind of like the XLR/Audio jack combined socket, although that is for compatibility.
Ultimately, though, you have to wonder whether the better solution would be just to use wireless charging. The most robust connectors are surely the ones you don't need at all.
"In theory. Whether anyone implements that properly in practice is a different question."
They do. I use a multiport USB B/USB C charger. The ports and cables are capable of supporting different power output. I can plug in my laptop at 45W, or a lower power device at 2W and it all works. User facing issues are minimal. Only some of the cables with a USB C ending will charge at 45W, so you have to know which ones work. And, we have one and only one device that refuses to charge at all of USB-C/PD to USB-C; it has to use USB-B or a dumb USB-C; why the PD doesn't just default to 2W charging I don't know.
It's been great; a single charger in the kitchen and we can do everything -- laptop, tablet, phone, powerbanks, bike lights. All of a single wall socket, kept in a wire basket with charging leads coming out everywhere.
No that isn't the problem.
"Requiring", "responsibility" -- this is the language of formal contracts. It's not the right thing within a single project which progress with social norms.
In any project there is a degree of obligation between upstream and downstream code. If you use someone elses API, then you have to fix your code if the API changes; that is your responsibility. But, whoever owns the API has a responsibility to think about the impact they have on you when changing that API.
The Rust people are building safe abstractions to large parts of the kernel. Which means that they are downstream of many parts of the kernel. Of course, maintaining those abstractions will be done by the people who know Rust; but that doesn't mean it can have no impact on the C development at all. But this is not different from when someone adds a new bit to the kernel in C.
Software dependency graphs may be unidirectional, but the social dependency this introduces are not.
This is the reason that Rust is not required to build the kernel, I think. You can still build a working version without. It's also (one of) the reason that there is work on GCC to make it compile Rust.
As Linus says, they have been at this for two years, which isn't really very long. There will be a long road till it becomes a required part of the build.
It isn't going to require core developers to convert. But as a Rust API is likely to have less undefined behaviour and certainly will place different requirements on the users and implementors of that API, it is going to require more clarity about the way things work.
When ever you rewrite something, try to add a new language or just have a new developer come on board, you are going to uncover corner cases, or unwritten assumptions that you didn't know or care that you were making. I think that this is all that happened here. Whether core developers want to engage with that process or not will depend on how much the value the inclusion of Rust. Some just won't like it; otherwise might be more worried about something else.
It's hardly surprising that in this process there are going to be some personal falling out.
You do wonder a bit about this post. The author spent 18 months coding in Rust. Their second big complaint is that there are no stack traces when errors happen. They also complain that the community is crabby and bitchy.
But in the comments it is clear that they acknowledge that there were no stack traces because they weren't switched on, and the crabby community was reddit; the author never looked anywhere else for somewhere nicer.
The other complaint is that the syntax is verbose and the semantics unintuitive in places; well 1 out of 3 is not bad. Maxing Rust less verbose and more intuitive is and has been a thrust of Rust lang development for the last few years.
The National Grid have published an article on this. Short answer is that electric cars are not necessarily a problem.
The key points are: a) not everyone charges at the same time, including development of infrastructure to ensure this: b) oil takes a lot of energy to refine, so we should recover 4.5kWh for every gallon of petrol not used and c) electricity consumption is falling from it's peak in 2002 by about 16%, while the grid has remained the same, so we can add 16% of energy use back without problems, of which about 2/3 would be enough for electric car needs.
And, of course, all of this is happening over time. It's not a single point in time. The grid is being rebuilt anyway -- consider recent interconnect with Denmark, new sea routes Scotland to England. If the Tory moratorium on onshore wind was removed that alone might be enough to increase capacity in a way that was (reasonably) distributed across the country.
https://www.nationalgrid.com/stories/journey-to-net-zero/electric-vehicles-myths-misconceptions
Cambridge got about half a billion from Horizon and similar amounts from it's predecessors, so I don't know where you get the idea that they avoid Horizon.
Yes, indeed, Horizon and EU management is fairly hard work and they do tend to want plans and milestones and all the rest. That doesn't fit brilliantly with science always, but then this is the way of large organisations, into which category the EU fits. A large part of this stems from difficulties in early versions of Horizon with some reasonably dodgy auditing.
The work packages are not prescriptive from the EU; the scientists who write the proposals write the work packages. After which, indeed, the EU want their deliverables.
You are correct that a lot of the training grants do require mobility, and cross-country mobility. I have my doubts about that. But the EU is hardly alone in this. Quite a few people in research believe that you need to move around to be exposed to the best ideas and for cross-fertilization. I can see the argument but at the same time, while some people value travelling and living in different parts of the world, it also makes life hard. It is difficult to buy a house and raise a family when there is a strong expectation that you move every three years. Still, hardly a surprise that money comes with strings attached and that it's expenditure is expected to achieve more than just "good science".
And, indeed, there are companies who specialize in bidding for EU money; just in the same way that there are IT companies that specialize in government contracts. Bidding processes are big and complex, as is the management afterwards. So you get specialists.
So, I agree with some of what you say. But that is quite a different from what you said which is that Horizon does not produce good science. It does.
What are your metrics for "producing good science", because you seem to have picked a single example, then said "well in the recent past that didn't get any Horizon funding". How far back in the history of mRNA vaccines have you looked? You will not have to look far with any discovery to find that publicly funded science is part of that chain sometime in the recent past.
Even in low-level code, the number of places that you need to do unsafe operations is limited. Rust still helps by specifically indicating where those regions are with unsafe blocks. And outside of this, there are lots of operations in Rust that are not unsafe, compared to C where they would effectively be.
Of course, Rust is not a panacea. What it might be is a little bit better than C which will help somewhat with avoiding problems. That's not a bad thing.
Well, use a memory safe language. Rust is, Golang is. They just have different mechanisms for achieving it. Golang is GCd. Rust mostly uses memory recovery at compile time and GC when it can't do runtime.
So, I think golang and rust exist for pretty much the same reason.
They work but only provide the basics in terms of convenience. For example, if you create a venv you still have to remember to activate it, either through an IDE, or on the command line (for which I use direnv. The functionality of pip depends on whether you have: `pip install numpy` will do different things depending. And, pip is not a project tool. If you copy my git repo, you need to create a venv and then run pip on requirements.txt. And, because there is no lock file, what you get might still be different from what I get. And if I have run `pip install numpy` previously, my repo might not work for you because I forgot to add it to requirements.txt.
And so on. pip and venv are potentially part of the solution, providing installation, dependency management and sandboxing. But they fall wall short in providing all of the solution. Python packaging is a mess.
I said that there are worse things you can do in. There are better things as well, and this is no doubt why they are or have fixed it.
In the end, Rust as a language is designed to protect against a number of things, including memory safety. Jumping and saying "look, here is a bug that is not about memory safety, it's all a waste of time" is hardly a strong riposte.
I think that your analogy is wrong. If you compare C to Python, you are being asked to trade your sleek racing bike in for a sturdy commuter. The latter is easier. simpler to use, safer but not as fast. Comparing Rust to C, I would say you are asking to trade your sleek road bike for another sleek road bike but with electronic gear shifts.
Of course, my analogy is a bit biased. Electronic gear shifts are getting pretty embedded now and will probably take over. Rust is rather less so. It's still in that stage where everyone is looking and thinking, cool, but will it work in competition use.
If you are a bike mechanic, getting the skills for all of these is probably wise. People will still be commuting. Club riders will be using a mix of electronic and manual for some time to come.
Damn it, I was supposed to be talking about programming languages....
The Rust community are completely fine with compilers written in C and C++ I think. After all, the main Rust compiler architecture is built on LLVM which is written in C++. There are several GCC/Rust projects, including a backend.
It will take a while I am sure, but then so will the process of adding rust infrastructure to the kernel as well as getting further acceptance.
There is no problem with calling the compiler directly. Rustc is available, documented and usable.
If you have a small amount of Rust and a complex existing build system, there is nothing to stop you going that route.
"There are no novel, original or unique features in Rust"
No. I would, indeed, not expect them to use features which were completely novel, not in a language which is intended for end usage. The combination is novel, of course, although that's true for most languages.
"Because that will quickly tell me if the authors have a clue what they are doing and where the likely points of failure are."
Okay, that's good, but you haven't said anything about these really.
You are indeed correct, I don't write compilers or commercial software; I write software to support scientific research and that is my expertize. That makes me experimental by nature. But people are using it to ship software, in real environments and it is currently gaining traction. Of course, Rust might disappear. Or it might grow in size and usage. That's why you try things. Or, at least why I try things.
This really rather reads like you are saying "they didn't do it right, because they did not do it the same as they did another language". You might be right, but the process of language design might be expected to evolve even as language design does.
The question of the spec comes up now and again. It's important to some, less to others. In the days of Common Lisp and, to a less extent, Java then a spec was important because it allowed alternative implementations, and avoided a control by a single vendor. Rust does not have this, however, there is an implementation, which is free to use, which will continue to be free to use, which is backed by a foundation, which will is dedicated to this end. So, a single implementation is not so much of an issue, nor is a "main" implementation with others tracking that. It works for python and many other languages.
A spec is required for some things, though. And so people who care about that are writing one. It will track behind the language and not lead it. Again, different from CL and C. But it means that the language can evolve and new things can be tried extensively before they become part of the spec.
You say that you have found several paths to subvert memory safety. That's fine. Rust is trying to provide a memory safe subset of the language, with minimized undefined behaviour. If you can find a way to subvert memory safety that is not marked as unsafe, then you have found a bug. If it is marked as unsafe, then the misunderstanding is yours.
Rust's stated aims are fairly clear and rather far from "implementing some personal pet features". You may not value these aims; you may not think it will achieve them, fair enough, but claiming there is not justification suggests that your "quick look" may have been too quick.
I don't think porting code from C to Rust is going to happen in that many cases. At the moment, it is giving the option for new drivers to be written in Rust. Whether, Linux ends up moving toward Rust more generally remains to be seen. But I doubt that much of it will be re-written -- it's just too big a task.
Of course not, but Rust has never given that guarantee.
What it does offer is that in a subset of Rust (the safe subset) if certain classes of memory issues do occur in a piece of code, then they are due to a bug in Rust, not a bug in the code. In C, you can introduce many forms of memory error in trivial code which, in practice, means you can introduce it in any code, without it being considered a bug in C.
In terms of the underlying optimisation and compilation, that is just an implementation detail. It's changes where the bug might need to be fixed, not that it is a bug. In practice, if this kind of issue occurs at the clang/gcc level, then it's likely to affect quite a few more languages than Rust.
Is that a big thing? Maybe, maybe not. What it does do is allow a separation of concerns. Some aspects of memory safety become the job of the Rust developers rather than the end developer. It's similar to the other things you described -- the end programmer does not has to worry about loop inlining or any of the many optimisations that are being performed at clang level. It is one trick that we don't have to use any more because it's done somewhere else.
"So there'll be a bit of a consumables cost."
With the current technology that would be but, who knows, if the sponge is either expensive or replacing it is expensive, they might find an alternative.
"Well, it kinda does given how sulphuric acid is produced. And that also kinda needs fossil fuels,"
Fossil fuels are deeply embedded in our industry, so pretty much everything needs fossil fuels. Solar panels and wind turbines use fossil fuels in their production. In this case, the sulphuric acid is a component of the system, not an input, even if it needs replacing occasionally. The system will use less fossil fuels as our society does.
"sulphuric acid is a popular drying agent that just loves water, but obviously that dilutes it, so it'll need a process to re-process the water,"
Or you could just electrolyse the water in the acid. You need an acid for the electrolysis anyway, and the electrolysis will drive of the water either way. It's quite clever actually. You use a natural property of the electrolyte to attract the water. So it should come with little extra cost.
It's a lot easier to organise inside the workplace than it is outside. That's one of the reasons that it has been a protected act for many decades.
Clearly there is a risk with a company like Amazon. At the same time, this kind of action exemplifies exactly the need for a union in the first place.
The number of variables can be determined at compile time. The number of values cannot. It's references that are one of the mechanisms for achieving this.
The value "5" is a different kettle of fish. Integers are fixed in size and usually take up the same amount of space as a reference. So most languages store these directly on the stack, rather than using a reference to the heap. You are wrong if you think that there is only one value 5 in a program; there could be any number and the compiler cannot determine how many 5s there are at compile time.
It can determine how many literal 5s there are, or expressions that always evaluate to 5 (i.e. constant folding). Again, there would still be multiple copies of "5" in the program, because there is no point interning an integer. Unlike, say, a string which might very well use an interned reference.
Of course, there are circumstances when it makes sense for "5" as a value to be referenced rather than stored directly, which is when you want to add some extra behaviour to it. Atomicity, is one example. Another is when 5 is not an bounded and fixed-size integer but a number you want to be grow to any arbitrary size or precision.
As for your last comment: c.f. previous argument about civility. It is a shame that you lack it.
Rust by default does not use reference counting at runtime. Rather it determines statically at compile time when the value associated with a variable can be deallocated and does this automatically for the programmer. There is no runtime cost associated with this.
This is not always possible, of course, for example if you intern strings created across a program to save memory. For those cases, Rust has support in the standard library for a reference counted pointer. Actually two. One for single threaded use and one for threaded use. Using the wrong one (i.e. using the single threaded one across threads) is a compile time error.
So, you pay the costs for what you need and pay no cost for what you do not need.
I don't know what a reference counting variable is either. References counting is done at the level of the value. The whole point is for where you cannot determine whether multiple variables point to the same value.
To bring it to the question of Rust, it does not reference count. The language uses a system of lifetime analysis to ensure that only one variable owns a value and that value outlives all references to that value. Mostly this is done statically. For the situation where it's too complex, Rust also provides library support for reference counting values. There are also libraries which do mark-and-sweep GC. I don't know how widely used they are.
Most people who use terms like "fanboi" and accuse others of being "clueless" do not actually have "inquiring minds", they just lack civility.
GO uses "critical sections" to address the realtime problem. I'm not sure that I would distinguish between reference counting and GC. Reference counting is a form of GC as far as I can see.
Rust doesn't GC by default, but it does provide a reference counting system -- so some of the values in a program are effectively GC'd and some not.
The semi-colon in Rust has some semantic beyond the end of the line actually. Or more the lack of one. Without a semi the line becomes a function return expression.
Feels a bit ugly when you start, but works out nicely once you are used to it. Having learned it, though, I find my python code keeps breaking, when I forget to put a return statement in a one line function.
"C [...] is still a bit faster according to the article".
Yeah, the article is probably wrong there. It's very hard to compare across languages, of course, but where it has been done Rust and C come out about as fast as it is possible to come out, and much the same. GO is also very fast, even with GC.
The article is also wrong about concurrency. Rust had this well before version 1.39, it just didn't have async/await as keywords. That should be obvious really. Who would design a single-threaded programming language in the 21st century?
I think most of the articles conclusions (lone programmers vs big groups) are equally suspect. Still, the title is fun.
There are more C/C++ programmers out there than Rust, so obviously, there are more people who can teach it also.
Having said that, Rust has produced quite a large quantity of fairly good documentation, freely available, as well as a number of books that you can buy. They have also a very good and supportive community. All of which is available world wide via the magic of the web. It's how I learned Rust.
Decreasing the learning curve, indeed, is a good thing. Some of that comes from your background. Javascript programmers will probably have an easier time than C programmers, because Rust is fairly functional. And some will come from the many "quality of life" improvements that Rust has made particularly to lifetime handling. I think it is easier now than it was four years ago when I learned it, although that's hard to measure.
You aren't the only one. Quite a few people have found GO easier to learn than Rust. Although Rust has a somewhat richer semantics, some of which GO will gain over time (like generics!), which will make GO more complex.
Rust has also got easier over time. The most difficult bit is almost certainly lifetimes, and "fighting with the borrow checker" must be the most common point at which people give up. But this stage is significantly easier than in the past because the language has changed.
It does have it's own package management system. It's rather better integrated with python than pip is which feels (and is!) a bolt on.
In terms of "3rd party" packages that it is a more complex question. Rust has gone the route of a small core, with add on packages for non-core functionality. That means it can offer somewhat different stability guarantees between the core/standard library and more extended functionality. How well this works we will see in time, but it should avoid the python/java standard library of cruft issue.
The hard bit of "3rd party" is, of course, that Rust is not a product of an standard organisation. The core/std library is produced by "3rd parties" in the sense that the code is not written by the company (or foundation) that owns Rust. So some "3rd party libraries" are effectively part of Rusts extended library support. Consider clap, for example, which does command line parsing. It isn't part of the standard library, but is used by rust-lang.org in their command line documentation. Would bringing it into the standard library magically make it more secure? Or just mean that it's release cycle would be tied to Rusts?
"Which means, in my bombastic opinion, that it has the potential of following the same path as ADA"
It could do. My feeling with Rust is that the learning curve is actually getting less over time. It's easier now to learn Rust than it was in the past, mostly because the compiler handing of the hardest bit (the lifetime and borrowing rules) has got a lot cleverer.
Of course, it's hard to be sure from personal experience; I learned Rust a while back and that it feels easier to me could just be that I am better at it, but I have heard similar anecdotes from others.
"C++/Rust/OOP further that sacrifice by the concept of a v_table (jump, jump)."
Rust isn't OOP though, and doesn't use a v_table. Most calls are statically determined at compile time. Polymorphism is achieved through the use of generics and the code is monomorphised to allow this.
There are exceptions because a dynamic dispatch allows you to do things that are hard otherwise. One of the changes with the Rust 2018 edition is the introduction of an optional keyword to mark usage; that will become a hard requirement for Rust 2021.
Well, C was a modern language once, so clearly you think that it lived to it's hype.
In the end, while there will always been some guess work, the real solution is to try things out, slowly and cautiously, see if they work and make an judgement at the end of it, rather than just assuming that "C is the safest bet" based on your prejudices.
Rust is designed to fill a hole and address a variety of problems that C does have. There is no serious doubt that C has its problems and allows a wide variety of bugs which occur with regularity. Rust is designed to address these; whether it will do in the context of the linux kernel or not is what we do not know yet. This is an attempt to answer that question.
I struggle to see how this makes sense. Good coders will use the tools that are available to them.
Rust is one of those tools, and having the code compile does indeed detect lots of errors that you might need to test for in other languages. More time fighting the compiler in its sometimes baroque ways; less time writing tests. That's an engineering compromise like any other.
I've stopped worrying about lift doors shutting one me also, and don't use a cloth when taking an light bulb out any more, so perhaps I am becoming sloppy and have too much blind faith.
> "The university's apparent belief that research can only be unethical if it involves human subjects is just plain wrong. "
I think it's the apparent belief that is wrong. The University will know that things other than human subject research can be unethical. In fact, in this case, the problem is likely that they hadn't worked out that it was effectively human subject research. My guess is they read "tool and method for discovering security flaws".
If they have read, "we will see if people can detect our attempt to deceive them", then the panel would have said no.
Ah, but which law is that?
In this case, the woman in question was 17. So capable of making an informed decision? Well, not in the territory that these events are said to have happened where the age of consent was (and maybe still is) 18.
It was foolish to have such a nuanced argument on an email list; it was likely to be misunderstood there as it is here, but that was the argument.
Rust is a little unusual in it's loops. But as `loop` and `break` generalize both `while` and `do while`.
The syntax is occasionally overly complex -- like most C syntax languages the paren matching can get a bit much; but it's okay to my mind. Then I like lisp, so perhaps I am odd here.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
