That's great and all Vates, and Imma let you finish
But taking care of the technical debt of being shacked to CentOS 7 should be more important
339 publicly visible posts • joined 10 Feb 2010
"in the kernel, the vast majority of it is unsafe."
yes, because it's C. It's ALL unsafe - even the logic that handles the internal data structures, which doesn't need to be unsafe. And the internal data structures is what makes the kernel.
"(gaining nothing). Thus pushback, as there is great risk for very little proposed benefit."
take your blinders off. Logic errors are easier to catch than CVEs. Errors in defined behaviour are catchable with tests, errors in undefined behaviour _might_ be.
"write firmware for hardware devices"
Oxide Computer Company - AMD Zen hardware initialization without a BIOS, IPMI control without actual IPMI, an embedded kernel, I could go on: https://github.com/oxidecomputer
"write applications and bindings to popular GUI frameworks"
Right, that's what's preventing people from using C#, not having proper bindings to Qt. Why not walk and chew gum at the same time? Unlike other memory-safety languages like Java or C#, Rust can be a used as a systems language - which is much harder, but where the gains would be bigger, and it's not something other memory-safe languages can do.
"standardise an ABI"
why aren't you in charge of the Linux kernel? what possible reason could the Linux kernel developers have for not standardising their (driver) ABI?
Again with the "unsafe" fallacy?
Having "unsafe" blocks locks down where serious attention must be paid - everything OUTSIDE the unsafe block is safe(r) than before. And that's not considering that safe code can (and should) armor the unsafe block from unsafe calls. So no, just because there is the possibility of breaking Rust's safety protections, and although that's basically mandatory for interaction with hardware, it doesn't render it useless.
For starters, bcachefs has nothing to do with Rust and that kerfuffle has happened because the main developer is over-enthusiastic, isn't used to the discipline and compromise of integrating in a larger organization, and tried to push a point-update into a Release Candidate window - found a bug that needs too much intervention to solve? Live with it, put it on "Known Bugs" and try again.
bcachefstools is Rust-related but it looks like another impedance mismatch between Debian maintainers wanting to have full lockdown of all dependencies but dependency handling in cargo being too dynamic; there may be something I'm missing, because cargo packages can be pinned; however, Debian's attitude flows from the Linux model of distro maintainers having to do all the work to keep the dependencies in check, which comes down from the general practice of dynamic linking and is becoming harder and harder, while Rust doesn't have to care because it only does static linking.
Linux is based on two contracts: "never break user ABI" and "we'll break kernel ABI whenever we want, but if you give us your driver's source-code under GPL, we'll maintain it for you to correct for those changes and you won't have to worry about that"; the latter has been a moat around Linux, because it ensures that nobody can create an alternative and have access to Linux's breadth of drivers and kernel modules, forcing all alternatives to wither and die for lack of hardware support. Maybe losing that lockdown is what Ts'o is actually so worried about, that RedoxOS (or Fuchsia) can ever become an alternative to Linux if Linux's driver-level bindings ever become stable enough for something else to be compatible with them...
https://virtuallyfun.com/2018/02/15/wanted-console-text-editor-for-windows/
where the author examined
Yedit (part of the Yori alternative shell for CMD.EXE)
Watcom VI
Kinesics Text Editor (KIT)
Minimum Profit
FTE
Clone of TurboC's editor called SETEdit (some assembly required)
X2 Programmer's Editor
Personal Editor (PE)
E3 Editor
Thomson-Davis Editor (TDE)
Microsoft Editor (MEP.EXE) - NT port of Z editor
Micro, of course.
However, most can't work with UTF-8, can't first-run from a raw binary like VIM (they need to install dependencies and DLLs) or have an x64 version.
IIRC, only Yori (and one or two of these, can't remember right now) tick all the boxes
No.
Is there a way to remove Safari Webview from iOS?
Is there a way to remove Android Webview and replace it with another Webview?
The OS vendor has to test against a controlled Webview.
More and more internal Windows components (edge://) will depend on that Webview, and it could have advantages, since Teams/Edge seems to be faster, slimmer and less buggy than Teams/Electron.
Gecko, in any shape or form, is not designed to be composable. Every time I asked someone always told me to go away, all you can build on top of Gecko is a web browser.
Now Servo has been designed from the start to be composable, but Mozilla kicked it out without a proper JS engine, which looks kind of fundamental to build applications on top of it.
This is rich, considering the article is explaining how everything being a file (a POSIX concept which the main author of NT railed against on the record) prevented Optane from being really useful because it HAD to be a file and HAD to be handled as a filesystem (secondary storage).
You mean 75% of the Rust code being initializing and setting up the HAL environment so your logic can remain the same if you swap RP2040 boards? Not worth it in this case, since the logic is so small, but have a larger thing to do and you can port it by just swapping values on the "bloat" section.
Write well, write once.
Because although Microsoft is moving to the command-line, and supporting SSH administration of Windows Server, a good CLI text editor for modern Windows is 404 in the base install. Which means I usually have to resort to gvim; and I've tried everything:
- YEDIT: not a real installer, not a self-contained executable, and not signed. The same author wrote what is by far the best alternative to CMD.EXE (YORI).
- Open Watcom VI: still exists in GitHub, unbundled from OpenWacom, but doesn't support UTF-8
- Kinesics Text Editor: needs Admin permissions to install, no UTF-8
- FTE: needs very old MSVC libraries
- Thomson-Davies Editor: no UTF-8
- Micro: Go port of Nano - but that's Nano, not CUA
>checks Tilde website
>no Windows binary
aw shucks.
You mean Microsoft's equivalent to Apple's HFS Resource Forks? From 1985?
It's amazing, a company tries to support advanced functionality and because everyone else can only think in flat files the advanced functionality is a mistake.
It's like UNIX "everything's a stream so just hack at the bytes" vs NT "everything's an object and you should use methods to handle them" - idiots try to hack at NT objects because that's the lowest effort option and get surprised when they blow up in their face, so that's *obviously* Microsoft's mistake.
Linux devs don't have to wonder; unless they keep up to date with the dependencies, their programs break with the next version of each distro. There was a time where you couldn't compile Samba from source on RHEL7 because of a missing library that had been marked as "deprecated" and "WONTFIX" by Red Hat. Samba!
No it isn't [/Cleese]
There must be something missing with your .conf, whenever I edited my resolv.conf the change was immediate.
In fact, for all the gnashing of teeth about systemd, base Debian netinstall is free of NetworkManager and Systemd-resolved out of the box, you have to go out of your way to activate them.
Of course, if you pile up "Desktop" and "GNOME" (phear!) in tasksel, all that cr*p starts to come to the surface...
OCP hardware is so different from anything else in a datacenter and needs so much specialty support that it only makes sense if you're deploying several rows of racks or you have a greenfield deployment; if you have just two or three racks it doesn't make sense, and Inspur won't return your calls anyway.
Mob rule is amazing. It's opt-in. It has been clearly stated and disclosed. Compared to Microsoft, Muse Group has been a model citizen. If you're worried about being silently activated after you opted-out, do you audit the source code of each and every patch you apply? Well, you should then. Might find that's all you do, and unless you're being paid to do just that, you won't get anything else done. Enjoy your bugs. Fix them yourselves, it's open source! Fork Audacity. Fork it from orbit. It's the only way to make sure.
Even a pop-up offering to send a report after a bug doesn't catch many categories of bugs, and most people hit Cancel on those anyway.
About the Google and Yandex integrations, they leave me uncomfortable, but should Audacity, which survives on contributions, spend contribution money creating an analytics platform?
Where's the open source and free as in freedom analytics platform with a worldwide CDN, guys? Isn't open source the solution to all problems?
That 70% percentage I quoted of vulnerabilities because of memory/data-race/side-effect? Microsoft et al. That's why they are firefighting it right now with Rust and have sponsored the Rust Foundation while developing an in-house equivalent codenamed Verona.
Apple is working on a Rusty Swift and although Google went to the trouble of hiring the best minds in language development to create Golang, they're still using Rust inside the Fuchsia kernel.
Look around. You may think all that software was reliable but how stringently was it tested, really? Did you have fuzzers back in the day like we have now? If you need to recompile it today, how much of its behaviour was defined by the choices of the previous compiler about what to do on the several places where a language has "undefined behaviour"?
Rust (or any similar language) can't help with errors in code logic. But it definitely helps with 70% of existing errors, which are of the memory/data-race/side-effect variety and that usually can't be caught in development, only in production. Rust ensures, at least, that if it compiles, it's mostly free from those.
Cue everyone complaining that Rust is hard and the compiler is slow...
Several forests have been decimated to produce MITRE code standards, but nobody follows them (Minimal Viable Product is the law of the land, security be damned) and even following them to the letter, C and derivatives should be classified "Unsafe at any speed", even (or especially) legacy code. Rip it all up and start again with GC/RefCount/RAII languages.
Nuke it from orbit, it's the only way to make sure.