Comments by "" (@grokitall) on "Brodie Robertson" channel.

@alexisdumas84 i am not suggesting that every rust dev wants the maintainers to do everything, only that those who don't are being conspicuous in their absense with dissenting opinions or are failing to see how their additional semantic requirements to get the type system to work cause a semantic mismatch between what information is needed to do the work, and when. for c, it comes when the patch is finished and you try and upstream it, at which time any such problems result in considerable rework to get from working code to compatible code. this is why the real time patch set took nearly 20 years to get fully integrated into the mainline. for rust, all this work seems to need to be done upfront to get the type system to work in the first place. this is a major mismatch, and the language is too new and unstable for the true costs of this to be well known and understood. rust might indeed be as great as the early adopters think, with minimal costs for doing everything through the type system as some suggest, but there is an element of jumping the gun in the claims due to how new the language is. python 3 did not become good enough for a lot of people until the .4 release, and for others until the .6 release. as you maintain your out of tree rust kernel, with any c patches needed to make it work, have fun, just make sure that when it comes time to upstream the maintainers need to be able to turn on a fresh install of whatever distro they use, do the equivalent of apt get install kernel tools, and then just build the kernel with your patches applied. it is not there yet, and thus some code will stay in your out of tree branch until it is.
1
@marcogenovesi8570 they do document them to the extent needed to do development work in c (in most cases), but the rust developers need even more information which the c developers don't need until it is time to upstream a patch, and an actual problem occurs, not just the potential problems the rust compiler finds. its like having ai find bugs. yes it can do it, but it cannot work out if it is a bug, a threat, or an exploit.
1
 @mikechappell4156 because it was obvious from the announcement of python 3 that 2 was on life support as far as the developers were concerned.
1
@mikechappell4156 totally agree, but once it was clear that the developers were going to treat it the way x11 is now being treated, it should immediately stop people from starting new big projects in it, and should have them start getting proactive about splitting the big code up so it can become less of a roadblock later when you cannot replace any code without replacing all of the code.
1
@sylviam6535 as they get closer to the core, not only will the existing costs increase, due to the larger interface between the two languages, but more and more code can only be extended in the second language, so as it moves closer to the core the risk of having to duplicate the code in the original language so the rest of the kernel can use it goes up a lot, making the benefits of those patches more doubtful, and increasing the push back against the encroachment into core kernel space.
1
the point is that in an enterprise setting, just moving away is not a question of just reinstalling one machine, it can be a multi year job covering thousands of machines. this is why rocky came into existence, to support centos 8 customers screwed over by red hat deciding to cut short the support period. be assured that a lot of rhel customers are saying internally that given the failures of trustworthiness and predictability, can we afford to use red hat for our next project rollout.
1
 @Mooooov0815 the sort of people this is targeted at will definitely be doing incremental development with continuous integration, where unit tests are not just good, but are essential.
1
 @pauldunecat if it is 19 years old, why does it need the nightly buildm9f the compiler to work with the rust in linux code?
1
there are a number of use cases where some form of automatic update is an anti feature. the classic example is the medical specialist remote working, who opened up his laptop to review a diagnostic image which needed immediate feedback, only to have windows trigger an immediate automatic update blocking use of the system for over half an hour. having systems where downloads are slow or expensive also need the option to defer downloading until you have a better connection. then you have laptops, where you might have to defer installation until you can plug it in to prevent partial updates from breaking things. finally, you need the update system to be pull based, as push based update systems add a whole extra set of problems if the push did not work. and all of that assumes that the update itself is not broken.
1
@monad_tcp micro kernels are clearly a better design, apart from one small problem, the message passing model is painfully slow in practice. numerous tricks were tried to find ways to speed up micro kernels, unfortunately the same tricks also seem to work just as well with monolithic kernels, so soon after a speedup occurs in micro kernels, the same speedup is also applied to the monolithic kernels, meaning that the gains were quickly negated. almost all kernels now are modularised monolithic kernels.
1
because the term predates the ideas behind the nix package manager, which tries to solve a different problem. its like saying lets just rename the make program to be called fred. yes you can do it, but the amount of issues it would cause is just not worth it.
1
If you watched the video, when you download it from upstream, everything is compiled in but turned off, so just recompile the upgrade and don't turn anything on.
1
No, the problem is that dispite a number of user complaints, it was ever promoted out of sid, which raises wider concerns as to what sid is for if not to stop this sort of breakage getting though to unstable.
1
the point is that it is not about you trusting your distribution, but them being able to audit the trust for everyone upstream of them so they know that the stuff they built has identical source and output as what was got from upstream. it does not stop the xz hack, you need other methods for that.
1
@Vegemeister1 restarting a cluster is a solved problem. You can use wake on lan to wake up a machine from powered down, and doing update and reboot works if the kernel or core libraries change. If they don't, you can just shut down the service and restart it. Bearing in mind the only time it makes sense to live patch is for high throughput systems, sharding gives much better scalability. In this sort of throughput scenario, you are basically talking about high availability systems, so having multiple machines as part of the system is already a given for reliability and resilience reasons, so sharing does not add much load at all. Tools like ansible even make this whole process relatively easy. I think it was Netflix who intended to reboot a specific machine and accidentally rebooted their entire data center instead, which only took a couple of minutes to come back up.
1
only the first time when the build does not match, and you can automate some of that. you are basically having to debug what is different in the builds. once it builds reproducibly, the tooling stops you having to do all of the work again.
1
@MaxusR which is the entire point of reproducible builds. if you cross compile gcc using llvm, and then use that on a machine with another architecture to cross compile llvm using gcc, you can be fairly sure that your new llvm install has not been hacked by the compiler. if i can then do the same thing, and get a bit perfect copy, we can both be sure that the same source code produces the same output. it does not stop the xz attack, but there are other parts of the supply chain testing which help catch that.
1
@warpedgeoid black box statistical ai has the issue that while it might give you the same results, you have a lot of trouble knowing how it got those results. this is due to the fact that it does not model the problem space, so is inherently about plausible results, not correct results. there is an example from early usage where they took photos of a forest, and later took photos of the same forest with tanks in it, and trained the system. it perfectly managed to split the two sets. then they took some more photos with tanks, and it failed miserably. it turned out it had learned to tell the difference between photos taken on a cloudy day, and photos taken on a sunny day. while this story is old, the point still applies. the nature of this sort of ai is inherently black box, so you by definition don't know how it gets its results, which makes all such systems not suitable for man rated and safety critical systems. symbolic ai like expert systems on the other hand have a fully auditable model of the problem space as part of how they work. this makes them just as checkable as any other software where you can access the source code. this is referred to as white box ai, as you can actually look inside and determine not just that it produces the right result, but why and how it does it. this sort of system should be compatible with aviation standards.
1
@klafbang what they are admitting is looking for ways to get the code without signing the eula, and this not breaching the rules of the eula. every business big enough to need a legal department looks for the cheapest way to do this sort of thing, and then looks for alternatives, and that is legal.
1
@MarkusEicher70 people have different needs, which leads to different choices. red hat built it's business on the basis of always open, and base yourself on us. later the accountants started to complain, and instead of reducing the developer headcount through natural churn, they decided to go on a money hunt, closing source access to a lot of people who believed them, thus causing the current problems. rocky, alma, parts of suse, oracle linux and clear linux exist to provide support to people left high and dry after red hat decided not to support the needs of those customers. as red hat is an enterprise platform, the support needs can be up to 10 years if you get a problem at the right part of the cycle. third party software is often only tested against red hat, so you either have to pay them the money and sign up to their dodgy eula, or use one of the derivatives. the open source mentality views access restrictions as damage and looks for ways around it. moving to other non derived distributions comes with added costs, as not all the choices are the same and the software you need might not be tested against those choices, so you have to do a lot of testing to make sure it works, then either fix it if you can get the source, or find alternatives. this adds costs, hence people getting annoyed.
1
ibm have a history of dumb moves, and still have corporate memory of the debacle of giving the pc market to microsoft. however it is clear from statements from red hat employees that the decisions are coming from the current management whose every action and statement shows that despite being in the linux ecosystem for over a decade, they have no idea how it works, or what it means to be an enterprise distro. talk about failing upwards.
1
@aheendwhz1 about halfway through the thread, he said that he was not only opposed to rust in his part of the kernel, even though by this point it had been made clear that he literally had to nothing but get out of the way, but that he was going to do everything he could to kill the whole project. That sounds like wanting to burn it to the ground to me.
1
people depended on python 2 because it wasn't perl 6, and it was the new and shiny. then they built huge monolithic apps in it in a way that was hard to split up, requiring a major rewrite of the entire application to move to the new version. really bad design, but that is the history, and they are making the same mistakes with ruby as well.
1
Windows is already dying, as Linux has already killed it. A lot of tasks that used to be done on only windows have moved to new platforms not run by Microsoft. The only place windows is not dead is the desktop, but most things are either moving down the tech stack to smartphones and tablets using apps, up the stack to be web apps, or are open source and open standards cross platform programs. In all of these cases the underlying os is either not windows, or not relevant. This process is accelerating, and once it has gone far enough windows will go the way of the horse and cart, only a lot faster.
1