1,037 karma · joined July 3, 2015
As a matter of fact "64-Bit-Only" is in the title of the article. That sure sounds like they are dropping 32-bit support, does it not?
As the poster said, they are keeping 32-bit ring 3 support, contrary to the title of the article.
I wrote a portability library that wraps these with compiler intrinsic and standard C fallbacks. I chose to spell out the full word in addition to making the type explicit. It's a lot more verbose of course but a lot clearer to read:
https://github.com/ludocode/ghost/blob/develop/include/ghost...
https://en.wikipedia.org/wiki/EleutherAI
They built GPT-J and GPT-NeoX.
Painting it as some kind of irrational fear is misleading and counter-productive. It is perfectly logical for Apple to forbid GPLv3 code.
Quite frankly, GCC committed suicide by switching to the GPLv3. Both Apple and Google have entirely abandoned it. Apple invested tens of millions of dollars into building Clang as a direct result of the license change. And now even the BSDs and many embedded Linux platforms have switched to Clang, leaving desktop Linux and a few esoteric systems as the only remaining use cases for GCC. Yes, GCC is still around, but no serious company will invest in GCC for anything new ever again.
- decl.qualified-return-type is comparing two very different syntaxes: a common C __typeof__ extension versus C++ decltype. This is hardly an example of code that compiles differently since it's compiling different code. In any case, there is a C23 proposal for typeof() which notes that it intentionally does not behave as C++ decltype(). It proposes an alternate syntax which might be called something like remove_quals() or typeof_unqual(). It will behave closer to C++ decltype() but still not the same because it will remove _Atomic and restrict which do not exist in C++.
- In stmt.decl-after-label, C23 will additionally allow a label at the end of a block. C++ does not. So they will still not match after C23 :). You need to put a null statement (a semicolon) after a label at the end of a block to make it portable.
- type.char8_t-literal will fixed by C23. char8_t will be a typedef to unsigned char and u8"" string literals will have type unsigned char[].
- In decl.empty-initializer, the C++ syntax will be supported in C23.
- expr.inc-dec-bool says ++ and -- do not invert the _Bool value. Is this implying that they do nothing? Because if so it does not match my tests. They behave as though +1 or -1 were applied to the value as an int, but then it is cast back to _Bool, so -- on 1 produces 0 and all other cases produce 1 (including -- on 0.) https://godbolt.org/z/f4Gvbqhbd
I live in Ontario, Canada. Almost all of my electricity comes from nuclear, hydroelectric and wind. Solar panels are not particularly efficient so far up north and they are covered in snow five months of the year anyway. Solar is mostly a waste of money here. (I still see the occasional house with solar panels but I mostly interpret it as a protest against nuclear power.)
Electric cars also don't fare particularly well in our winters. It's pretty hard to go visit family out of town when your car has half its stated range. I'm of the opinion that pervasive plug-in hybrid vehicles would do far more to reduce our collective carbon emissions and buy us time to get plug-in hybrids with renewable fuel (biodiesel, ethanol, hydrogen, etc.)
Heat pumps I agree would help. Unfortunately my country has huge amounts of cheap natural gas. Until carbon taxes start ramping up and heat pumps are subsidized I don't think most people will willingly increase their heating costs.
These things only work if everyone does them. If we want people to give up their cars we need massive investment in electrified public transit. Without that it is impossible for most people to survive without cars. A few people who have the freedom and the will to suffer under public transit choosing to give up their cars will do nothing to stop climate change.
Lately I've been catching up on the state of the art in bootstrapping. Check out the live-bootstrap project. stage0 starts with a seed "compiler" of a couple hundred bytes that basically turns hex codes into bytes while stripping comments. A series of such text files per architecture work their way up to a full macro assembler, which is then used to write a mostly architecture-independent minimal C compiler, which then builds a larger compiler written in this subset of C. This then bootstraps a Scheme in which a full C compiler (mescc) is written, which then builds TinyCC, which then builds GCC 4, which works its way up to modern GCC for C++... It's a fascinating read:
https://github.com/oriansj/stage0
https://github.com/fosslinux/live-bootstrap/blob/master/part...
Even if no one is "using" this it should still be a primary motivator for keeping C simple.
I say "sort of" because if he's truly concerned about the effort involved in creating independent implementations, then obviously he should be evaluating features by the difficulty involved in implementing them. typedef and typeof are absolutely trivial to implement [0] [1]. typedef just creates type aliases and typeof is very similar to sizeof.
Also, I'm not sure what 1000 functions you're referring to, but most functions being added are already in POSIX and already exist in a huge number of independent libc implementations. There are dozens of POSIX libcs, including at least 5 totally independent implementations for Linux alone that are still fully maintained and under active development.
[0]: typeof: https://github.com/rui314/chibicc/commit/7d80a5136d1b2926dd0...
[1]: typedef: https://github.com/rui314/chibicc/commit/a6b82da1ae9eefa44da...
I went pretty deep into composable C templates to build mine so it's more powerful than most. The containers can handle non-bitwise-movable types with full C++-style lifecycle functions and such, and the sort algorithms can handle dynamic and non-contiguous arrays (they are powerful enough to implement qsort() [1], which is more than I can say for any other C sort templates I've seen.) My reasoning for the complexity at the time was that any powerful container library is going to be reasonably complex in implementation (as anyone who's looked at STL source code knows), so it just needs to be encapsulated behind a good interface.
I'm not so sure that's true anymore. These sorts of simpler libraries like the one linked here definitely seem to be more popular among C programmers. I think if people are using C, it's not just the C++ language complexity they want to get away from, but also the implementation complexity of libraries and such. There's a balance to be had for sure, and I think the balance varies from person to person, which is why no library has emerged as the de facto standard for containers in C.
[0]: https://github.com/ludocode/pottery
[1]: https://github.com/ludocode/pottery/tree/develop/util/potter...
I'd say on some platforms "horrifically slow" is an understatement. At my day job we were building software in Cygwin on Windows machines infected with Symantec's virus scanner which adds hundreds of milliseconds to every process launch. The configure script for Protocol Buffers took something like half an hour to run.
We eventually switched to CMake but not without a lot of pain first. For what it's worth, CMake fixes the speed issue but not much else. It still has its own totally esoteric custom language, it still discourages globbing source files and requires re-running upon adding any file or changing anything, and it has even more insane default settings than autotools (for example file(DOWNLOAD) from an https:// URL by default ignores certificates!)
There is something wrong with all of these buildsystems. I don't know what the solution is but I feel we are very far from it.
Is this satire? What is going on in this thread?
Author here. That wouldn't be so bad; it's kind of how it works on Android. An app can just request permission to access the entire external storage. It's not exactly the home dir (there's no potential for auto-starting scripts) but it's similar. The permission prompt is still useful because it's something you can decline; you're not forced to agree implicitly to install the app.
But anyway what I want is to install and run GIMP and Excel and Photoshop completely unsandboxed. I think it's silly to try to sandbox every app. The insecure world is still the world of Windows today and it's the dominant platform by far, in part because of the freedom it provides to software vendors.
I do actually prefer traditional installers, which is why I like GOG so much. Good installers will just put their app data into ~/.local/share/<app>, put an icon in ~/.local/icons and a desktop file in ~/.local/applications, and provide an uninstall mechanism to clean it up. There's no mess here, no root required, no accumulating gunk. Longer term, these installers could automatically write AppStream metadata so that the installed app appears and can be uninstalled through the distribution's Software app, like Add/Remove Programs in Windows.
Regardless of what I prefer, the fact is the biggest software vendors will never allow their software to be sandboxed. Look at how Adobe Creative Suite or Microsoft Office are installed on Windows and macOS. They aren't in the OS app stores. They have their own custom installers that handle login, keep the apps up to date, do DRM checks, etc. I'm sure this is not what you want, but it is what they want, and if they can't get it then they just won't port their software to Linux.
https://docs.nvidia.com/datacenter/cloud-native/container-to...
> I hope you can see that "keep libraries backwards compatible forever" is not really a good option
??? Why would I be able to see that? You've given zero explanation or evidence for why that would be the case. I see a whole lot of people in this thread in addition to the article explaining why backwards compatibility is good. Nobody is giving valid reasons as to why it's bad.
Microsoft has managed to keep the whole Win32 API compatible "forever". GUI apps built for Windows 95 still work out of the box on Windows 10. Backwards compatibility is a major part of why they are still the dominant platform: businesses actually care about this. They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time. A platform that breaks their software is no platform at all.
> probably orders of magnitude more work than just doing all the things you said.
Really? How hard is it to not break things?
It's sometimes more work to add new features or support new hardware without breaking the ABI but clearly it's feasible. glibc 2.1 was released in 1999 and the maintainers decided at that point that they would preserve backwards compatibility forever. We're now at 22 years without a major ABI break. There have been some hiccups of course (the memcpy() fiasco) but they've been fixed.
The GCC team have decided to follow in their footsteps. Since version 5 they've decided they're not going to break the libstdc++ ABI anymore. The culture of backwards compatibility is finally growing on the Linux desktop. This is a far better solution than Flatpak.
Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespaces to load different version of libstdc++ into the same process. Flatpak is not there yet.
For another, NVidia drivers complicate this even more. The NVidia client-side library must exactly match the version of the loaded kernel module which Flatpak can't control. So NVidia drivers are broken out into yet another runtime extension, and it can't package these drivers due to licensing issues so it will dynamically download NVidia drivers to generate an extension on the fly. NVidia drivers also depend on libstdc++ by the way, another reason why static linking doesn't magically solve the problem.
On top of all this is just the massive complexity and maintenance burden of keeping all this working. All these runtimes with all their extensions, somebody has to keep updating these, and when a runtime is deprecated all of the software that was built for it is defunct. All of this can be solved just by keeping libraries backwards compatible and building for native Linux, not Flatpak or anything else.
It's also how the Linux Standard Base worked. It was intended to be a stable well-defined backwards-compatible set of libraries common across distributions. Of course the LSB had its share of problems but they had the right idea to bring stability to Linux as a platform for binary apps.
I know you think we should all just drop our masks and stop caring if the unvaccinated get COVID. I get it, and I'd love to not care. But they fill the hospitals, wasting my tax dollars and affecting my family's ability to get treatment.
> Full hospitals don’t matter. They are private companies who had more than a year and a half to prepare for this. Expecting all of society to bail them out? No thanks.
This is so backwards I don't even know where to start.
First of all, hospitals in my country, like many (most?) Western countries, are not private companies. Here they are owned and operated by municipalities.
Second of all, you can't expect all hospitals to prepare for a massive temporary influx of patients. Where are they supposed to get the doctors and nurses? You think a whole country can just double or triple the amount of nurses in a year, and then lay them all off afterwards when the pandemic is over? Where are they supposed to get the space for these patients? You think it's quick to build a hospital? Where are they supposed to get the money to do this?
Third of all, are you not worried about getting in a car wreck and having no ambulance available to come save you because they're all busy picking up unvaccinated COVID patients? Because this is a real thing that is happening right now. I'm guessing you're a fan of private health care; are you not worried about your costs spiking because you're now in competition for medical care with countless unvaccinated COVID patients? "Full hospitals don't matter" is the most backwards and ignorant comment I've seen on this. This absolutely matters to you. It directly affects your ability to get care.
You do understand that lockdowns are basically the opposite of mask and vaccine mandates right? Masks and vaccines help us avoid lockdowns and get back to normal. Yet all of the people I see complaining about lockdowns are the same people I see refusing to wear masks and refusing to get vaccinated.
The most important reason there are mask and vaccine mandates is that hospitals are already overloaded with unvaccinated COVID patients, which means no one else can get health care. Cancer patients (like my family member) are dying due to lack of treatment. People with sudden injuries (like from car crashes) can't get a bed in a hospital. If we completely remove all restrictions it would get much worse.
Another reason is that not everyone can get vaccinated. My kids are under the age limit for the vaccine. Obviously their risk of death is low, but their risk of long COVID may not be. It bothers me that people who interact with my daughter on a daily basis (like two of the mothers of other children at her daycare) refuse to get vaccinated.
I am also working on and off on my C template library Pottery [2]. I haven't pushed any code in a while; having a day job and young children makes progress slow :(
Besides, none of your examples require that a human actually be inside the vehicle. They could all be done by unmanned drone. The only reason to put a human in the vehicle is to travel.
Now if they replaced the human with its weight in batteries, or better yet a hydrogen tank with a fuel cell, this would give it a huge flight time which would make it much more useful.
A fine is obviously not sufficient given how widespread this practice is. If the fine is double what you gained but you are less than 50% likely to get caught, logic dictates you should commit the crime. Again, prison is the only deterrent that works on the rich.
The benefits went to the executive directly. He asked for personal bribes to sign contracts on behalf of Netflix. He enriched himself at the expense of his employer. This is illegal.
In any professional project I've ever worked on, the compiler version has been strictly controlled. The entire team must use the same version of Visual Studio, or Xcode, or the JDK, or the Android build tools or whatever. You don't just let your developers upgrade whenever they want. Upgrading the build tools is an involved process that must be coordinated with the release cycle. All new warnings need to be fixed, all CI nodes need to be upgraded at once, scripts and metadata need fixes to work with the new tools, etc.
You are only approaching this issue from the perspective of open source software. That is not most software. The parent is correct: the compiler version is a dependency of your project and, in any serious development team, should be fixed for the whole team.