Posts by DrXym 5327 publicly visible posts • joined 18 Jul 2007
Sadly 25 years of existing Windows software will never get rewritten. If Microsoft treat all that software - productivity, games, music players, intranet, open source etc. as an afterthought, as a second class denizen that either doesn't run or suffers poor performance / emulation, they may as well toss Windows 10X onto the bonfire with all their other failed efforts.
Since every single desktop, laptop and tablet / folio device does its own thing. Some copy Apple style keyboards, others offer chunkier keyboards with more travel. But perhaps that's the point. If you hate Dell laptops you can use one by Lenovo or whichever manufacturer produces one to your liking.
A lot of the early Android tablets failed Google's minimum specs and requirements for certification so they shipped without Google. Archos for example did it.
I hope somebody provides an easy way for Huawei's phone to sideload GApps because otherwise their offering will be as useful as a chocolate teapot.
There's certainly an argument to be made for putting things like this into the standard library. It doesn't prevent 3rd party libs from offering alternative / better / finegrained ways of doing the same, but it reduces the amount of dependencies that are required for code that just wants to do something straightforward.
Languages like Golang have adopted this "kitchen sink" approach to their libs. Even Java has a pretty extensive http support in its runtime but you can always use Apache Http instead if you want.
Your last comments get to the point. C++ and C typically only offer one advantage over higher level languages - performance.
If your software spends most of its life waiting on the click a button, or network IO, or disk IO, or some event that happens twice a day then maybe it's not a good language to write the code in. Or if the software needs to be reliable, or portable, or maintainable then the same.
I think this is the very obvious reason that C++ finds itself shoved out to such things as graphics, games, systems and some embedded stuff. Even in those places, I suspect people resent the bullshit C++ puts them through - null pointer exceptions, overflows etc. This would explain why Rust and Golang are increasingly seen as alternatives.
C doesn't have strings AT ALL. That's the problem. There is no intrinsic string type of any kind. Instead you have a pointer to a char and the "string" is all the chars before a nul char.
As you say it has caused all kinds of overflow issues. A trivial one is a buffer too short to copy the string into, or off by one byte for the nul char. And even though C has "safe" string functions, it never bothered to remove the unsafe ones. So the likes of strcpy are still there as an attractive nuisance.
The situation is somewhat better in C++ but it doesn't have a string intrinsic either. Instead it has a std::string template class. This maintains the length of string as well as the string itself so it doesn't rely on a nul char but it sticks a \0 on the end anyway for c_str().
Erlang has GC but it's still used extensively in telephony systems and other (soft) realtime applications. I think it's more the case that most garbage collected languages don't give programmers the control / guarantees necessary to absolutely assure performance for certain tasks. In Java, Javascript, .NET or Golang you are at the mercies of the runtime.
I definitely agree about Rust. While I would never rewrite a C++ program for the sake of it, Rust would be my defacto choice over C++ unless there were reasons it couldn't be.
Or C or Rust or some other language with predictable behaviour from one second to the next. Even languages like Erlang that has GC is still suitable for many soft real time actions.
It's also important to mention that if you DON'T need low latency, or where something like disk / network latency is the biggest speed impediment, then using a language like C++ can be an invitation to a world of unnecessary pain.
I can understand why GitLab wants to pad out their reviews for this site because to the casual observer it only divulges a few written reviews before clamming up and demanding a visitor divulge salary and other personal information to see any more. So if the top reviews seem glowing you may be getting a false impression.
More generally I wonder if Glassdoor is like Yelp and other social review websites. I'm sure companies affected by negative reviews are contacted by Glassdoor sales reps offering to "improve" their image for money (i.e. make bad reviews disappear). And there will be external services trying to boost or extort companies for $$$ by posting fake reviews that move the rating one way or the other.
The problem with the LGPL is that most of the newer Qt components are actually GPL3. So if (for example) you were doing an in-car infotainment system that needed to use the virtual keyboard, or wanted a remote QT app through the web, or something with a locked bootloader, you'd be screwed.
The Qt licence is particularly punishing for embedded uses where it is per-device as opposed to a flat developer licence fee for desktops.
I don't think there is any problem for any open source software built over any version of Qt any way they see fit providing it abides by the LGPL / GPLv3 as appropriate.
Wasm's "means of accessing the outside" is whatever the embedder chooses to expose. In a browser that means exactly the same access to the outside world as JavaScript - the DOM, canvas, web audio etc. with all the same cross origin & security model checks. Anything that a browser stops you doing in JS it would also stop you doing in wasm.
Not even sure what to make of the "native code" comment. The point is the specification describes a low-level instruction set and binary / text format without dictating how the implementation should run it, or whether it uses JIT, AOT or neither.
This is as opposed to an plugin / activex control which *was* a native DLL with same privilege to do anything in the OS as the process running it.
Wasm doesn't have a standardised runtime or any runtime per se except for what the embedder (e.g. a browser) exposes to it. If you look at emscripten for example, one of things it does is provide a C, C++ and SDL compatible libs that map through onto the DOM / canvas / webaudio / OpenGL in a browser.
If you're worried about your battery being sucked dry then advocating for a slower, more CPU intensive language doesn't seem sensible. As for crypto miners, I suggest you look at the sites you're visiting. I'm sure they've been quite happily serving JS crypto miners up until now.
The thing I like about Rust is it's safe by default and if you do need to do potentially dodgy stuff then you must enclose it in an unsafe block. You can simply search and find it with ease. I realise actix has gotten flak for some unsafe blocks but I see the fact that people could even see and review them as a feature not a bug.
Let's say ads did get a performance boost and that you're not running an ad blocker. So now your phone also gets a performance boost. Multiply by however many hundreds of millions of phones are showing ads at any given time.
But it wouldn't just be for ads of course. Any website, or web application which has complex or computationally expensive JS could benefit from the switch. WebAssembly is even supported by NodeJS so there is the opportunity to speed up server side too.
I honestly don't even know what to make of your "reliable" argument. That same reductive argument could be applied to anything new. Oh who needs electric bulbs when we have gas lamps! Who needs gas lamps when we have candles! etc.
But please cite what you think this other, "more reliable" way is. There have been three main ways that C++ software has been able to run in a browser in the past.
1. Via a plugin. This was dropped a long time ago because the bindings were horrible, installing them was horrible and vulnerabilities were per-plugin and often necessitated frequent updates outside the browser's own.
2. Via Empscripten. This produce Javascript which essentially emulated a processor and address space. It was pretty cool idea but painfully slow and ad hoc. e.g. if I compiled a C++ program it was dumped out as a big JS that had to be parsed before anything would run and occupy a large footprint in memory even as it did. It also runs very slowly because it emulates the C runtime. Even asm.js (a simplified subset of JS that browsers could potentially optimize codepaths for) didn't improve performance as much as desired.
3. NaCl / PNaCl. These were a Google proprietary precursor to WebAssembly. It was a good concept that was proven in Chrome/ChromeOS but being a proprietary meant it was never a good fit for the web.
A side note to all this, is that JS wastes a lot of power. That might no mean much in isolation but it should when we're talking about mobile devices or sites which are accessed millions of times a day.
WebAssembly will have issues to iron out along the way. Nobody is denying it. But there is a clear and obvious need for it as anyone who has struggled with JS performance or maintaining logic either side of the client/server divide could tell you. It's not going away. If you feel worried about it, disable it for the time being or use a browser that does.
Nothing to stop malware like bitcoin miners from running in JS even today. They could even use asm.js to optimize their performance and obfuscation to hide their purpose. If you're worried about such things, the best defence is not to visit sites that are likely to host them, or mitigate the threat by turning off 3rd party JS or using a proxy like Opera Mini.
WebAssembly runs with the same privilege model as JS so it doesn't really have the potential on paper to be any more of a threat that JS. But it is less mature than JS so there might be implementation bugs yet. Mitigate the threat in the same way as you would for JS.
Europe tried this before relying on the good faith of phone manufacturers to comply, i.e. allow micro-USB charging of phone devices. Except Apple decided to be dicks about it and only allow micro-USB charging via a dongle.
It should be mandatory for phones to support a single charging format and Apple should not be allowed to escape either by using dongles, or by moving to wireless-only charging.
But really Europe should be going further to combat waste by mandating that consumer devices such as laptops, phones, tablets, earbuds etc should be user serviceable with regard to replacing the battery. And that other vulnerable components such as the screen should be serviceable by independent technicians.
The flipside to that argument is why doesn't it come out of the factory with good settings? You know, like any sane software. If you're such a power user you can turn on stuff which might be hidden by default.
And the usability issues in LibreOffice are far more than the amount of context-free junk in the menus & toolbars even if those are an obvious example.
Navigator demonstrates my point. It shows TWELVE sections including esoteric things like OLE objects. Why can't it show just the things my document actually contains? Do you not see the usability benefit of removing that noise from the UI? It's a trivial example of clutter that serves zero benefit. And Navigator could be redesigned to better serve what people mostly use it for - as an ersatz outline view because Writer has no such mode. I dare someone who hasn't used Navigator before to even figure out what half the buttons in the view even do. It's certainly no substitute for outline view that's for sure.
Usability issues like this are replete through the tool and as I said, it's death by a thousand cuts.
What I find odd is the negative reaction to usability. It's as if some people equate this with copying Microsoft's ribbon, or junking features. Usability does not mean that at all. It just means making features easier to find and fit for purpose (taskcentric, forgiving, intuitive etc.). Assuming you actually want open source software to succeed then this has to be taken on board. Or we'll be having this same conversation in a year from now, and a year after that when a new LibreOffice drops without confronting these issues.
My biggest problem with LibreOffice is clutter in the menus and toolbars (esoteric / advanced stuff mixed in with the common), unforgiving actions where Do What I Mean was forgotten, visual glitches (e.g. resizing a splitter or the window makes it flicker / paint damage like crazy), and a million and one little quirks and nuisances that litter the user interface. Some of the tools in the suite suffer more than others but they all do to one degree or another. It's death by a thousand cuts.
I think LibreOffice should focus on usability for a few releases, overhauling the experience so it is decluttered, task centric and forgiving. New features are always nice but Microsoft gets the usability right too and I suspect that is a primary reason that companies still prefer to pay for it than use a free alternative.
I have no idea if Amazon's proposal was the best or not, but it is abundantly clear that Trump meddled with the process from the very beginning because he bore a grudge against Bezos and the Washington Post. And if their solution was the best then let the implication sink in - Trump just materially harmed the US (again) by saddling it with an inferior solution because of a personal grievance.
I can't recall the number of times I've been a bar / restaurant / hotel and their stupid wifi either blocks sites, or tampers with the content (e.g. to inject ads). A very large number of American news websites even block European IP addresses rather than fix the site to comply with privacy rules. And video streaming & game services can get very annoying if they think you're in the wrong country.
So having a VPN is a very handy tool even if you aren't in an oppressive regime. I can't say I use them all the time, but I like to have one available for when its needed.
relibc is a C POSIX library. It's there so Redox can run ports of software compiled with other languages like C. Other Rust software wouldn't use it directly though I suppose it could come in indirectly if there was a crate that depended on a C library which depended on relibc.
I expect the safe/unsafe situation in the rest of Redox largely depends on context - something that is interacting with hardware, lowlevel structures or gnarly scheduling stuff might be unsafe, but the remainder, the majority is going to be safe. It would be interesting to count the relative amounts of safe & unsafe code but let's remember that all C code is unsafe.
It's hard to address your non sequitur so I won't directly except to say this.
Rust stops entire classes of bug from becoming compiled code. You *can't* call a null pointer because you don't use pointers in safe code. You *can't* data race because all multi-threaded structures must be protected by guards. You *can't* leak memory or double free because the compiler knows the lifetime of every object and inserts the mallocs and frees for you. Not only this make safer code but it allows *your* code to be less conservative and make better use of threads and concurrency because of the protections afforded by the language.
And unless your business likes unhappy customers, and surprise production delays then you want to catch bugs as early as possible. That's why the Rust compiler kicks your arse if you do things wrong. The sooner a bug is squashed, the quicker it is time to market and the happier the customer is.
That doesn't mean you rewrite C/C++ code for the sake of it. But if you're writing from scratch or rewriting anyway, then there is a potential huge payoff for considering switching language.
The thing I found about Rust is I unlearned some of my C and C++ practices and wrote safer code in those languages. It also made me more cognizant of code patterns which Rust would kick my arse for writing so at least I would try and isolate and make as safe as I could knowing the compiler wouldn't help me.
At the end of the day though I don't think Rust's way of thinking is actually hugely different from C and C++. It just forces you to write safe code or it won't compile at all. That incurs a lot of pain and suffering up front but saves you (and testers and customers) a lot of pain and suffering when the code actually compiles and runs.
I program Rust and it would be nice if it formally supported do-while. But you can actually write a do-while using this slightly weird code:
fn main() {
// Print numbers 0 to 9
let mut i = 0;
while {
println!("i = {}", i);
i += 1;
i != 10
} {}
}
The block after the while evaluates to a boolean expression so it's doing stuff, evaluating the result to true or false and then has an empty block of code.
Mozilla *isn't* a C shop and hasn't ever been really. There are some C libraries in Firefox (e.g. NSPR, libxml etc.) but the majority of the browser engine is written in C++. The majority of the front-end (i.e. the user interface and services wrapping the engine) are written in Javascript. Things are bound together with something called XPCOM which is basically a cross-platform version of COM where proxy / stubs & interfaces are derived from interface definitions.
Mozilla is currently developing a new browser engine called Servo and are replacing chunks of the existing engine as that becomes ready. Servo is written in Rust and the hope is that they can make the engine far more concurrent than it is now without worrying about many of the problems that plague concurrent C++.
Dyson gave up on their EV plans. Probably realised it was ever-so-slightly more difficult to design a new car than a vacuum cleaner.
Personally I think there is far easier way they can get into the automotive space. Lots of cars brag about their branded sound systems, but how many have branded air conditioning systems? Dyson have an easy "in" there.
Well that's an odd way of looking at it. I wonder if you also use the "well we're not into manufacturing" as justification for the successive waves of automotive sector bad news that happened, completely by coincidence, in the last few years? The UK basically excluded itself from any chance of getting this factory through its self-inflicted situation.
The UK could have made a compelling case for Tesla to have built there if it had the same will and self-interest as Germany. It's not some backwater lacking infrastructure. But Brexit pissed any chance of that happening down the drain.
Thank goodness for Linus. He produced an functioning kernel in rapid time and provided the impetus for people to improve and expand on it - new architectures, networking, file systems etc. This is pragmatism in action.
And the reason he did this was because he was annoyed by the glacial pace of development in the Hurd project. Hurd was all politics and doing things "right" which may explain why 29 years later Hurd still hasn't seen a 1.0 release.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
