Well, when we talk of Apple, every other entity, commercial or amateur, is a competitor. Apple sells a hardware/software bundle.
This is many words without any reasoning. Show me the so called âcompetitionâ.
Untill we have arrived at the portless, transparent, magic glass slab there will always be incentives to keep enhancements to yourself. This is especially true if you are a company, like apple, that actually makes money off of hardware. (and not of targeted advertisement : P)
I still dont see the competition. We are talkin about industrial behemoths, they just simply cant loose anymore, because they have monopol position thanks to having all our data. There is no competition anymore. They have already won, sadly for us it means we lost.
Because you do not see it it does not exist?
No, i dont see it, because it doesnt exists. Small, but important difference.i was born in a communist country, last time i have seencomparable âcompetitionâ was during the 80âs.
In my humble opinion, Apple sells a whole unity of hardware and software. It has the image (by marketing) that it is engenious, superior and unique. Thatâs why people pay more money than they would have to pay for a comparable PC with Windows. If an OS turns out to be good on Apple hardware, this âmagicâ and marketing collapses. And that threats the hardware sales, too, because people donât need Apple HW for such an OS.
I was thinking more of companies like nVidia and other chip manufacturers.
But, still, there are sometimes some surprises found also in later steps, for example the software running on the âembedded controllersâ on laptops.
I guess it also depends which manufacturers you look at. Some indeed just follow reference schematics and donât change anything. Other do a bit more work to get a few more minutes of battery life, or such small things. Usually (if done right) it doesnât result in too much work for the OS developers, but there are some cases where it does, either because they did not do their job right and we have to apply a software workaround for it (and no hardware manufacturer would admit this openly) or because there is no standardized way for what theyâre doing (for example, the HDA audio driver which we have to change and adjust on every machine because the audio routing can be done in so many ways).
Apple, designing both the software and hardware for their machines, moves some more things into software, that other manufacturers would do in firmware. There are both upsides (more control for the user, if you want to replace the software) and downsides (more work to get the system working with non-Apple software).
Custom Hardware Cores
Open hardware based on RISC-V accelerates the demise of 3rd party operating systems because any real competitor in the market space can start to embed commonly used capabilities of their operating system directly into the instruction set of the RISC-V CPU using custom coprocessor cores. Though the core instruction set is open, nobody is obligated to keep their coprocessor cores non-proprietary.
Back in 1998, I hoped this would happen to the almost defunct Amiga computer but the tables have turned. The big companies today can make custom CPUs using the likes of the Chisel language with the Hammer backend to accelerate the development of custom cores with advanced System Verilog generators. In short, software is developing hardware to the extent that customization is no longer an option but rather: a neccessity and a requirement.
Application of the Concepts of Customization
If you think that the custom hardware of the Amiga was wierd, literally anything capable of running WebAssembly ABIs under stanardized APIs will likely come to have an endless supply of ports while those that do other novel and unusual things, whether in hardware or software, will be left behind the curve because the instruction set will become the language and WebAssembly compliance will become the operating system. The scary part is that Amigaâs custom hardware and Haikuâs stack-and-tile features will never be realized as necessary under the WebAssembly working groupâs standardization processes. In short, both needed custom code to take advantage of the novel features of the design. Unfortunately those custom apps may not come nor keep up.
How to come out on top if my predications come to pass:
- Keep the OS small with few novel features
- Keep the Hardware manufacturers on friendly terms (Donât make enemies of them. We may need them later.)
- Stay out of the mindset of being strictly a software or hardware developement design team. The lines will become blurred more and more over time.
- Keep a close eye on gate layout design tools like the Chisel language on the software side and FPGAs on the hardware side.
- Finally, embrace the idea that the most fundamental parts of an OS will become custom hardware in the future.
Another stuff :
even an alternative OS would be flawlessly easy to install on the machine the people who socialized in Windows often do not want to do efforts to learn the other OS how could they use or what program is that for them similar what they used oin Windows.
This way is so popular the ported programs â even if they wonât fit in every aspects related to ânativeâ ones.
The comfort wins over the practical and/or usefulness.
Drivers are key factors surely - but only for power users and open minded users - who wants to use an another system.
This way I do not understand among us whom envision crowds of people using Haiku - and giving advices what should develop as just that missing from Haiku to reach out those peoples to get Haiku.
They want belong to a big user based OS and they struggle to drag Haiku in their dream position where to they would put their finding â hoping vendors then would recognize and support it as it happened in case Linux.
They do not see how marginal was/is Linux support as âdesktopâ by big vendors. USB and BT stack was developed by several open source communities and that did available now that some devices enlist Linux besides Windows and macOS these days. However today can be some device that can be fully used under Win or macOS due to the software written for use it. Think about gaming/content creator PCs specific control softwares that can adjust all RGB stuff , tailor a computer to a specific game or toss graphic chips which one used for when that program runs.
This is not new at all. MIPs has been allowing this for decades, it was used in the first Playstation for its geometry transformation engine.
Likewise, some ARM CPUs implement Java bytecode in hardware or have some instructions specifically dedicated to speeding up javascript, and there are some with custom support for specific software (I worked in the past for a company using such things).
Custom hardware did not kill 3rd party OS then, and it will not kill them now. As long as there is documentation or someone can reverse engineer things, that is not considreably more difficult than implementing support for any other kind of hardware.
Can you please stop turning every thread in this forum into about a discussion of WebAssembly?
2 Likes
My point was that hardware descriptor language compiler technologies are accelerating the development of custom coprocessor extensions. If I thought they were new, I wouldnât have mentioned the Amiga. Ultimately my prediction is that new developments will outpace the rate at which reverse engineering can decode their designs.
The idea that full documentation is unlikely to come out of the likes of Appleâs M-class ARM chips and future versions of the Microsoft Surface makes this concept threatening to 3rd party operating systems.
Compiler technologies are seldom profitable by themselves but when they are combined with a runtime technology, whether itâs an operating system or embedded controller or high-level language instruction set or any combination of those, ignoring them will bite you in the butt every time.
Bytecodes are a means of making closed source software more portable. My point is that the driver codes can be merged into the instruction set of custom hardware more easily as compiler technology permits. WASM is just the latest bytecode on the block but its incorporation into browsers made it harder to ignore.
Finally, why the hyperbole? Iâve started threads and finished them without mentioning WebAssembly. Only the subjects that compiler technologies have influence on benefit from the bytecodes.
This topic is about open hardware, I think pulkomandyâs point was that you have a talent for taking a topic and spinning something ontop to then bring it all back to webassembly.
Honestly though: Itâs just a bytecode.
If we wanted to distribute as bytecode to compile on device LLVM IR would make way more sense, but enough of that topic.
1 Like