Linked by Thom Holwerda on Fri 31st Mar 2017 21:55 UTC
Google

Fuchsia is a new operating system being built more or less from scratch at Google. The news of the development of Fuchsia made a splash on technology news sites in August 2016, although many details about it are still a mystery. It is an open-source project; development and documentation work is still very much ongoing. Despite the open-source nature of the project, its actual purpose has not yet been revealed by Google. From piecing together information from the online documentation and source code, we can surmise that Fuchsia is a complete operating system for PCs, tablets, and high-end phones.

The source to Fuchsia and all of its components is available to download at its source repository. If you enjoy poking around experimental operating systems, exploring the innards of this one will be fun. Fuchsia consists of a kernel plus user-space components on top that provide libraries and utilities. There are a number of subprojects under the Fuchsia umbrella in the source repository, mainly libraries and toolkits to help create applications. Fuchsia is mostly licensed under a 3-clause BSD license, but the kernel is based on another project called LK (Little Kernel) that is MIT-licensed, so the licensing for the kernel is a mix. Third-party software included in Fuchsia is licensed according to its respective open-source license.

Great overview of what Fuchsia is and what it consists of. Google is really experimenting with some different approaches here. Definitely worth a read - before you comment.

At this point, it's really hard to fathom what Fuchisa's part is in Google's strategy, if at has one at all. It's too big, and involves far too many notable people, to 'just' be a research project, but at the same time, they're literally doing everything from scratch with some radically different ideas here and there, which makes it unlikely that we're going to see it replace Android or whatever any time soon.

My guess? Google is clearly having issues with Android in that it doesn't control the whole stack, causing Google to be at the whim of chip makers to maintain support for the Linux kernel, leading to the massive problems with Android updates we all know and hate. Fuchsia seems to be Google's response to these problems.

I'm not saying Google will replace Android with Fuchsia - I'm saying Fuchsia is the answer to the thought experiment "if we could start over, what would we do differently?"

Order by: Score:
Sorry this is more interesting.
by oiaohm on Fri 31st Mar 2017 22:44 UTC
oiaohm
Member since:
2009-05-30

http://memcpy.io/android-enabling-mainline-graphics.html

This is joint project between Collabora and Google's Chrome OS team.

So Android custom video driver design could disappear. Maybe google is working out what Microsoft did in the end. Let hardware makers produce unaudited drivers and they will break things.

Windows driver quality only improved when Microsoft started demanding signed drivers with the threat to ban them if the drivers were not up to quality.

Reply Score: 2

RE:
by MrMIPT on Sat 1st Apr 2017 15:53 UTC in reply to "Sorry this is more interesting."
MrMIPT Member since:
2017-04-01

You are talking nonsense. Signing with company certificate has nothing to do with drivers quality. Signing is attestation that the Company has released this driver. That is all.

Microsoft never threatened to ban any signed driver. BTW there is no mechanism in Windows to blacklist drivers. If a driver has a valid certificate it will be loaded. Microsoft doesn't manage certificates this is responsibility of the certificate signing authority.

Edited 2017-04-01 15:59 UTC

Reply Score: 3

Comment by Licaon_Kter
by Licaon_Kter on Sat 1st Apr 2017 00:04 UTC
Licaon_Kter
Member since:
2010-03-19

> ...causing Google to be at the whim of chip makers to maintain support for the Linux kernel...

Can you elaborate on this, exactly who is gonna write the drivers then, Google?

Reply Score: 2

RE: Comment by Licaon_Kter
by Thom_Holwerda on Sat 1st Apr 2017 00:09 UTC in reply to "Comment by Licaon_Kter"
Thom_Holwerda Member since:
2005-06-29

The Linux kernel lacks a stable ABI, forcing chip/device makers to continuously update their drivers. This is a design choice by the Linux Kernel team - and their reasoning is not without merit - but it does mean Google is at the whim of chip/device makers to keep up with the ever-changing Linux kernel.

With their own operating system, Google could do this entirely differently, and be far mor clear and consistent in this department than Linux is or ever will be.

Edited 2017-04-01 00:09 UTC

Reply Score: 4

RE[2]: Comment by Licaon_Kter
by oiaohm on Sat 1st Apr 2017 02:13 UTC in reply to "RE: Comment by Licaon_Kter"
oiaohm Member since:
2009-05-30

The Linux kernel lacks a stable ABI, forcing chip/device makers to continuously update their drivers. This is a design choice by the Linux Kernel team - and their reasoning is not without merit - but it does mean Google is at the whim of chip/device makers to keep up with the ever-changing Linux kernel.



This is only ever partly true.
https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html#wri...

Linux kernel does in fact have stable ABI for driver development. Only one catch. You driver will run in userspace.

Fuchsia there is no kernel space drivers. So hardware vendors supporting it will have to live with the fact they will have to make userspace driver.

Samsung did a classic example of why you don't want closed source drivers in kernel space. /dev/mem was removed because it was a huge security risk. Some of samsung code depend on it so instead of rewriting that code samsung added a new device /dev/something I cannot remember name. The new device was a straight up copy of /dev/mem security flaws and it did not have to have third party auditing.

So the reality is closed source drivers need to be got out of kernel space. Either by it being open source so they can be audited and maintained. Or the closed source driver need to use the stable ABI for userspace drivers that can be wrapped by protective frameworks to reduce possibly of harm.

If those who were making closed source drivers used the stable ABI from the Linux kernel no problems. If those making open source drivers were mainlining as well there would also be minimum trouble.

But we need google to put their foot down. Like you cannot particular android trademarks if you driver support is done wrong leading to upgrading issues. So closed source drivers must be userspace and open source kernel space drivers have to be mainlined.

Fuchsia could be a threat to hardware makers if they keep on doing closed source drivers in kernel space google will remove that possibility completely by changing kernels. Stuff the performance hit they take from being stuck in userspace.

Reply Score: 2

RE[2]: Comment by Licaon_Kter
by silviucc on Sat 1st Apr 2017 05:55 UTC in reply to "RE: Comment by Licaon_Kter"
silviucc Member since:
2009-12-05

It is entirely possible to ship android 7 without moving to a newer kernel than the one shipped when the device had android 6 on it.

That's how a lot of manufacturers do it. They keep the stabilized kernel (and thus drivers) and ship the updated userland stack of whatever Android version they want to ship.

The problem is that in the case of Samsung, Asus, Huawei, Xiaomi , etc... they modify the the stock android userland so heavily and choose to maintain it out of tree that merging a new version is absolutely brutal. So delays happen. Plus they have to choose whether they're going to sell you another phone one year later, or keep updating their older model while making no money out of you.

Guess what they'll choose.

Reply Score: 5

RE[2]: Comment by Licaon_Kter
by Treza on Sat 1st Apr 2017 10:33 UTC in reply to "RE: Comment by Licaon_Kter"
Treza Member since:
2006-01-11

Windows lacks a stable driver ABI, every Windows version breaks lots of drivers.

The most complex ones, graphic drivers need to adapt to new versions of DirectX, OpenGL. And there are often issues.

Now imagine that the chips are not made by large specialized corporations as AMD or nVidia, with dedicated software teams refining drivers for many years, but by small companies assembling blocks ("IPs") from many vendors. And a phone, with radio, GPS, is more complex than most computers.

Switching from Linux to an obscure proprietary OS would only worsen the problem.

Reply Score: 0

RE[3]: Comment by Licaon_Kter
by MrMIPT on Sat 1st Apr 2017 15:57 UTC in reply to "RE[2]: Comment by Licaon_Kter"
MrMIPT Member since:
2017-04-01

Windows has the most stable driver API among all major operating systems in use. Windows still able to load drivers designed for Windows NT4 and Windows 2000. Stable API has been one of the major selling point for Windows.

Reply Score: 3

RE[4]: Comment by Licaon_Kter
by Lennie on Sat 1st Apr 2017 20:10 UTC in reply to "RE[3]: Comment by Licaon_Kter"
Lennie Member since:
2007-09-22

API and ABI are not the same.

API is programming interface and ABI is binary interface aka binary compatible.

Have you ever noticed how most drivers come with multiple binaries in different directories with Windows versions in the name like amd64/win7, etc. ? That's because many times it's not ABI compatible.

Reply Score: 3

RE[5]: Comment by Licaon_Kter
by MrMIPT on Sun 2nd Apr 2017 15:45 UTC in reply to "RE[4]: Comment by Licaon_Kter"
MrMIPT Member since:
2017-04-01

You continue to spread nonsense. Windows have the both API and ABI backward compatibility. Your example is pathetic - you can't run 32 bit driver on 64 bit kernel.

You can still load a driver compiled in 1999 for Windows NT4 on Windows 7 if you disable driver signature enforcement which has nothing to do with ABI compatibility. Windows ABI is so backward compatible that I have used to have a single 32 bit binary for NT4/2000/XP/Vista/7 .

Reply Score: 1

RE[6]: Comment by Licaon_Kter
by Alfman on Sun 2nd Apr 2017 16:15 UTC in reply to "RE[5]: Comment by Licaon_Kter"
Alfman Member since:
2011-01-28

MrMIPT,

You continue to spread nonsense. Windows have the both API and ABI backward compatibility. Your example is pathetic - you can't run 32 bit driver on 64 bit kernel.

You can still load a driver compiled in 1999 for Windows NT4 on Windows 7 if you disable driver signature enforcement which has nothing to do with ABI compatibility. Windows ABI is so backward compatible that I have used to have a single 32 bit binary for NT4/2000/XP/Vista/7.


Well, sometimes drivers do break for reasons other than driver signing requirements and x86 code size. I've seen a lot of windows 7 drivers stop working in windows 8 or 8.1.

For whatever reason, new versions of windows aren't always 100% backwards compatible though even accounting for driver signing and x86 code size. If users are lucky, they won't necessarily notice because the vendors have already updated drivers, so it's not a problem.

Ideally there needs to be a good balance between everyone's needs.

Edited 2017-04-02 16:17 UTC

Reply Score: 2

RE[6]: Comment by Licaon_Kter
by oiaohm on Mon 3rd Apr 2017 00:02 UTC in reply to "RE[5]: Comment by Licaon_Kter"
oiaohm Member since:
2009-05-30

You continue to spread nonsense. Windows have the both API and ABI backward compatibility. Your example is pathetic - you can't run 32 bit driver on 64 bit kernel.

This is not 100 percent true. You can run 32 bit driver on a 64 bit bit kernel as long as it a user space driver. In fact you can go more insane of crossing architectures. Like using qemu to emulate x86 on arm so you can use a x86 only printer driver under Linux.

It is very important to understand the difference between a kernel space driver and user space driver. User space driver provides some massive advantages.

You can still load a driver compiled in 1999 for Windows NT4 on Windows 7 if you disable driver signature enforcement which has nothing to do with ABI compatibility. Windows ABI is so backward compatible that I have used to have a single 32 bit binary for NT4/2000/XP/Vista/7 .


Due to CONFIG_MODVERSIONS in most Linux kernels you can at times load modules for a 2.0.40 kernel in a current day kernel. And that is from 2004. Will it load all modules no. Will you system be stable afterwards who knows. Same with loading a NT driver in modern windows you don't know if the system will be stable and not all drivers will load some will be straight out rejected.

It is possible to intentionally write a driver for 2.0.40 Linux kernel and newer. They answer is yes. Is the driver horible absolutely.

http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/

Yes you can wrap a Linux usermode up into a Linux kernel mode driver basically removing the context switch overhead and that beast will work from 2.0.40 to current.

The reality here is there is a stable Linux ABI it refereed to as the user space ABI. It is usable from kernel space and user space.

There is a catch you should not mix using kernel ABI with using userspace ABI its the path to locking hell.

So if the userspace ABI for writing drivers in Linux sux. So does the in kernel stable ABI of Linux for writing drivers because they are the same thing.

So all the call for a stable kernel ABI for writing drivers is people ignoring that one exists. Then people writing drivers not using it. Why because the stable ABI for writing drivers is slower than the unstable one.

Edited 2017-04-03 00:03 UTC

Reply Score: 2

RE[5]: Comment by Licaon_Kter
by bassbeast on Sun 2nd Apr 2017 22:37 UTC in reply to "RE[4]: Comment by Licaon_Kter"
bassbeast Member since:
2007-11-11

Sorry but he's right and you're wrong, AAMOF I've had to on many many occasions at the shop load seriously old drivers into new versions of Windows and as long as they are the same bit and made for the NT arch? They work just fine.

I've loaded Win2K Pro drivers into Windows 7 (customer had a $4k professional printer that hadn't been supported since Win2K) and I've had to load WinXP drivers into a Win 8.1 system because the capture card he had was by a company that had gone out of business. this is just 2 of the frankly many dozens of examples over the years and the only issues I've had is unpacking the drivers as some of them used 16bit installers that haven't run in modern Windows in ages.

This is one of the big selling points of Windows, you can keep your expensive hardware and I've done it countless times. Linux lacking a stable ABI frankly really hurts it because if you don't have a dev dedicated to keeping that old hardware alive? Well a user here gave just one example of what a lack of an ABI gets you...

http://www.osnews.com/permalink?562009

Reply Score: 3

RE[4]: Comment by Licaon_Kter
by oiaohm on Sat 1st Apr 2017 22:26 UTC in reply to "RE[3]: Comment by Licaon_Kter"
oiaohm Member since:
2009-05-30

Windows has the most stable driver API among all major operating systems in use. Windows still able to load drivers designed for Windows NT4 and Windows 2000. Stable API has been one of the major selling point for Windows.

This is mostly fiction yet it has been a selling point. Modern version of windows loading a NT4 driver is totally out.
https://developer.microsoft.com/en-us/windows/hardware/windows-drive...
Look at the development kit. Windows 7 to modern Windows can at times use the same drives.
XP back to NT 3.5 at times can use the same drivers. If you happen have vista you are kinda in no mans land.

Fuse was added to Linux 2005 this is 4 years before Windows 7 that is 2009. First generation Fuse drivers can be run on current day Linux kernel no problems.

We are now getting to the point where the stable driver ABI of Linux is more stable than the Windows driver ABI. There are a lot of embedded system that mandate long term maintenance where all the non mainline drivers are userspace drivers on their Linux platforms.

With the existence of fuse and other user-space ABI options to create drivers with the oldest being fuse and its more stable than Windows provided Driver ABI this make me wonder if the linux kernel developers call is 100 percent right.

Basically if you stop quoting fiction and start looking at Windows driver compatibility and Linux compatibility across versions very interesting story comes out.

Including Windows binary drivers doing like All-winner does on Linux kernel.

Both stories end up reading very much the same. Windows allows binary drivers into kernel space. Windows suffered from failures when kernel updates from drivers doing stuff that upstream was not excepting. So Microsoft end up having to demand signed driver program.

Linux kernel developers see the same problem. Binary driver in kernel space equals failure to be able to update kernel. Its not like Linux Developers did not try to implement a shared kernel binary driver between Linux, BSD.... before throwing in the towel on the idea of kernel mode binary drivers.

https://www.cs.hs-rm.de/~kaiser/Slides/gutheil-weisser.pdf

Lot of different groups are using Linux usermode drivers these days because it is ABI stable. They are finding only a 5 percent hit being in user-space compared to driver being in kernel space. This sound bad until you wake up this is still on average higher performance than what windows can provide. Maintaining all those unchangeable in kernel structures comes at quite a performance hit to Windows.

So stable ABI for Linux driver development exists and is in use. Its now how to get the closed source driver makers off there kernel space addiction and use the userspace ABI. Also get bad driver makers of open source out of just dump the code on-line and not mainline anything.

As AMD has found attempting to get DC functionality into the Linux kernel a huge number of faults are found in the peer review process.

One of the things is to make it very clear as end users we don't want binary drivers in linux kernel space and have google and vendors demanding the same thing. There is not enough performance difference between a Linux kernel mode driver vs a Linux usermode driver to cover security cost of restriction in kernel updating to have a binary driver.

My point of view is Linux kernel has delivered a stable driver ABI. It now all about getting the closed source driver makers to use it. Using it will also allow it to be feature improved.

Reply Score: 2

RE[5]: Comment by Licaon_Kter
by Brendan on Sun 2nd Apr 2017 06:45 UTC in reply to "RE[4]: Comment by Licaon_Kter"
Brendan Member since:
2005-11-16

Hi,

This is mostly fiction yet it has been a selling point. Modern version of windows loading a NT4 driver is totally out.
https://developer.microsoft.com/en-us/windows/hardware/windows-drive...
Look at the development kit. Windows 7 to modern Windows can at times use the same drives.
XP back to NT 3.5 at times can use the same drivers. If you happen have vista you are kinda in no mans land.


A driver for XP will work for any version/build of XP (and same for Vista, Win7, Win8, etc), and won't break when there's an update (unless the driver does something extremely wrong). That is what "stable driver API" means - "stable (for the life-time of the OS it was designed for)" and not "stable between completely different products/OSs from MS-DOS up to Win10".

Fuse was added to Linux 2005 this is 4 years before Windows 7 that is 2009. First generation Fuse drivers can be run on current day Linux kernel no problems.


File systems are not device drivers.

We are now getting to the point where the stable driver ABI of Linux is more stable than the Windows driver ABI. There are a lot of embedded system that mandate long term maintenance where all the non mainline drivers are userspace drivers on their Linux platforms.


No, where getting to the point where the lack of a stable driver API is forcing some people to use ugly hacks that try to turn a monolithic kernel into a "micro-kernel with interfaces designed for monolithic (which are poorly suited and suck)".

Both stories end up reading very much the same. Windows allows binary drivers into kernel space. Windows suffered from failures when kernel updates from drivers doing stuff that upstream was not excepting. So Microsoft end up having to demand signed driver program.


The story is always the same - allowing "untrusted" drivers in kernel-space is a security disaster waiting to happen. Microsoft use signed drivers in an attempt to mitigate the risk. Linux insist on "open source" in an attempt to mitigate the risk (and that is why they don't want a stable driver API - it ruins their "wet paper bag" security model).

Linux kernel developers see the same problem. Binary driver in kernel space equals failure to be able to update kernel.


Yes, but this is "failure by design" - they deliberately make sure everything breaks by not having a stable driver API.

My point of view is Linux kernel has delivered a stable driver ABI. It now all about getting the closed source driver makers to use it. Using it will also allow it to be feature improved.


I agree - we should abandon Linux and use a micro-kernel.

- Brendan

Reply Score: 2

RE[6]: Comment by Licaon_Kter
by oiaohm on Sun 2nd Apr 2017 11:02 UTC in reply to "RE[5]: Comment by Licaon_Kter"
oiaohm Member since:
2009-05-30

A driver for XP will work for any version/build of XP (and same for Vista, Win7, Win8, etc), and won't break when there's an update (unless the driver does something extremely wrong). That is what "stable driver API" means - "stable (for the life-time of the OS it was designed for)" and not "stable between completely different products/OSs from MS-DOS up to Win10".

This is complete load of garbage because it does not match the facts. A drivers for XP without service packs a lot fail when users installed SP2 that changed the kernel. Windows 7 SP1 does a kernel change and breaks stack of driver again. Windows 8.0 to 8.1 again kernel change again stack of driver broken. Windows 10 recently a kernel change broke drivers and their computer would not boot any more. Even Windows 2000 and NT4 did a kernel change in the service packs and suffered from failed drivers after it. To find a version of Windows where it worked you are back to Windows NT 3.5 reason why there is no failure is no kernel change.

Now in today security issue world not changing kernel at all is not exactly good thing.

The reality we need to accept the fact kernel mode driver ABI stability is fiction. Asking for the Linux kernel to provide kernel mode driver ABI stability is asking them to-do something Microsoft has never pulled off when ever they change the kernel.

File systems are not device drivers.

Fuse includes something called Cuse.
https://lwn.net/Articles/308445/
Cuse is character devices or everything you need to-do an audio device and many other types of devices from user space. So fuse is not just file systems.

So since you saw the file system you never looked at what FUSE could in fact do so missed the birth of Usermode hardware drivers on Linux..

No, where getting to the point where the lack of a stable driver API is forcing some people to use ugly hacks that try to turn a monolithic kernel into a "micro-kernel with interfaces designed for monolithic (which are poorly suited and suck)".

80+ of direct hardware control drivers on Linux is only two driver types. char device or block device both doable from user-space under Linux. And has been so for over 10 years. Another 10+ are network drivers that can be done from user-space as well on Linux.

So this is again not wanting to admit the Linux kernel has a stable ABI for driver development just it user-space not kernel space.

The story is always the same - allowing "untrusted" drivers in kernel-space is a security disaster waiting to happen. Microsoft use signed drivers in an attempt to mitigate the risk. Linux insist on "open source" in an attempt to mitigate the risk (and that is why they don't want a stable driver API - it ruins their "wet paper bag" security model).

Another pack of garbage that does not match history.


Signed drivers come in Windows XP was not for security at first it was mostly to avoid loading Windows 2000 and before drivers without warning the user about stability issues. Yes the message was stability not security. The security issues come out of Microsoft later you are rewriting history to suit yourself. Microsoft introducing sign drivers was over ABI instability that those pushing binary ABI in kernel space keep on ignoring.

So you have effectively forgotten why Microsoft added signed drivers in the first place. Security is a bonus effect of signed drivers not why Microsoft were added signed drivers.

I agree - we should abandon Linux and use a micro-kernel.

I do not exactly say that. There are some classes of driver that never will suit a micro-kernel due to needing direct cpu control features. It between 1-10% of all drivers.

My option is Linux kernel could be slimmed down. A pure Microkernel does take performance hits with particular classes of drivers why Microsoft went hybrid in the first place. We need a hybrid between micro-kernel design and monolithic design that is more sane. Everything is in kernel space need to be under 1 parties control who can see all the source code so they can in fact understand if a change in kernel space is going to have horrible effects.


You need to see Micro kernel interfaces to the user-space drivers and you need monolithic design in the kernel space so you have a system getting maximum possible speed with highest possible security sweet spot.

Saying Micro-kernel or Monolithic are choosing design with weaknesses that the other one does not have. Hybrid what the NT kernel design is how to have the worst of everything why starting processes is so slow in windows.

By the way the performance overhead of usermode drivers under windows is average of 15% compared to running inside windows kernel space. This is 3 times worse than usermode driver under Linux. There is something very import for performance about doing the kernel space monolithic instead of kernel space following Micro-kernel ideas.

So a Micro-kernel user-space with a monolithic core design is the ideal. Linux kernel could be over time converted to the ideal. Just for Linux kernel to get to the ideal is accepting what history has shown us.

Why is kernel driver ABI stablity fiction. It quite simple. When you are running in kernel space you can direct access all the memory of kernel space. Hello problem if my driver presumes kernel memory looks like A as it did in the first version but now kernel memory looks like B and my driver does alteration get ready for kernel crash. No matter how much you document how driver should use the ABI you will always have drivers in kernel space due to optimisations and the like presuming the wrong things and altering places you are not expecting. Hardware mechanics don't allow you to provide binary drivers in kernel space that are stable end of story.

Micro-kernel idea with drivers in user-space the memory they are access is controlled the memory can be fiction by the kernel. So what the user-space driver sees looks like A but that is a wrapper in kernel to map to to B the kernel is now using. The userspace driver cannot be optimised to access anything that was not intended to be exposed. So yes you can write a userspace driver ABI that in fact works and even better supports multi versions of the userspace driver ABI been used side by side with each other.

So it about time people stop asking for the impossible and we focus on what is possible.

Reply Score: 2

RE[7]: Comment by Licaon_Kter
by Alfman on Sun 2nd Apr 2017 15:55 UTC in reply to "RE[6]: Comment by Licaon_Kter"
Alfman Member since:
2011-01-28

oiaomn,

This is complete load of garbage because it does not match the facts. A drivers for XP without service packs a lot fail when users installed SP2 that changed the kernel...Now in today security issue world not changing kernel at all is not exactly good thing. The reality we need to accept the fact kernel mode driver ABI stability is fiction. Asking for the Linux kernel to provide kernel mode driver ABI stability is asking them to-do something Microsoft has never pulled off when ever they change the kernel.


Criticize windows for all of it's numerous problems and mindboggling idiocy and disregard for users, but dismissing the stable ABI as fiction is blatantly untrue, you know better than to say this. You can dismiss Brendan, Thom, me, and others about our need for stable ABIs, but understand that from our points of view you're merely throwing problems under the rug without solving anything. Even as a developer I find it would be helpful to have ABI stability at least within major versions.


So since you saw the file system you never looked at what FUSE could in fact do so missed the birth of Usermode hardware drivers on Linux..


The performance isn't there. Instead of arguing this point here on osnews, I'll just point out the fact that mainline linux developers themselves are not going this route. Unless linux's own filesystem drivers will be converted to fuse, then this is just hypocrisy (aka: do as I say, but not as I do).


I've thought about it a lot over the years and while I support open source I personally can't endorse the practice of making technical decisions (like whether or not to use FUSE) over licensing squabbles. I can understand the motivation for some to do it, but in my own world view making decisions based on technical merit is more important than license based discrimination. For example many users find it stupid that distributing linux with ZFS has been fraught with issues because ZFS uses an incompatible open source license.


So it about time people stop asking for the impossible and we focus on what is possible.


Except that nobody has suggested doing anything "impossible".
I know linux evangelists feel the need to dispel every criticism of linux, but still some criticism is warranted. Can you admit that the truth is somewhere in between and that there are both pros and cons to the ABI choices linux makes? Linux's non-stable ABI is simply not the best choice for all users & developers, some of us really would benefit from having stable ABIs.

Reply Score: 3

RE[7]: Comment by Licaon_Kter
by MrMIPT on Sun 2nd Apr 2017 16:01 UTC in reply to "RE[6]: Comment by Licaon_Kter"
MrMIPT Member since:
2017-04-01

You continue to show that you have zero experience in kernel development ( any - Windows or Linux ).

Drivers failed on updates not because ABI was chanhed but because drivers had bugs that manifested themselves on new kernels. There were two reasons - either a call to KeBugCheck had been added to BSOD the system when a kernel detects inconsistencies OR the change of the timing/internal implementation revealed the bug.

Signing was not an attempt to improve drivers quality but an attempt to stop kernel malware from spreading. Signing procedure doesn't check the quality of a driver it just signs the code with a certificate which is usually not available for malware developers.

Reply Score: 1

RE[7]: Comment by Licaon_Kter
by Kebabbert on Sun 2nd Apr 2017 20:10 UTC in reply to "RE[6]: Comment by Licaon_Kter"
Kebabbert Member since:
2007-07-27

"A driver for XP will work for any version/build of XP (and same for Vista, Win7, Win8, etc), and won't break when there's an update (unless the driver does something extremely wrong). That is what "stable driver API" means - "stable (for the life-time of the OS it was designed for)" and not "stable between completely different products/OSs from MS-DOS up to Win10".

This is complete load of garbage because it does not match the facts. A drivers for XP without service packs a lot fail when users installed SP2 that changed the kernel. Windows 7 SP1 does a kernel change and breaks stack of driver again. Windows 8.0 to 8.1 again kernel change again stack of driver broken. Windows 10 recently a kernel change broke drivers and their computer would not boot any more. Even Windows 2000 and NT4 did a kernel change in the service packs and suffered from failed drivers after it. To find a version of Windows where it worked you are back to Windows NT 3.5 reason why there is no failure is no kernel change.
"
Well, I have missed this. I know that many people confuse things, and believe that a driver for WinXP should work on Win10 - and when it doesnt work, they draw the conclusion that "Windows have no stable ABI", Well, that is wrong. Windows is compatible within the same version, i.e. XP drivers all work on XP versions, Vista drivers work on all Vista versions, etc. Microsoft never promises that WinXP drivers work on Vista. Sometimes they do, though.

When I have used Windows during all these decades, I never had driver problems within the same versions. I dont know what you refer to, but the most probable thing is you mixed up concepts. Windows have excellent driver compatibility within Windows versions.

However, Linux is a mess. Upgrade the kernel and things break now and then. Have you missed all the forum threads about sound stopped working, or usb camera stopped working, etc - when people upgrade Linux kernel? There are loads of them. Just look at any random Linux forum and you will see lot of such threads.

I dont know really in which reality you live in, but even the largest vendors on the planet have huge problems with Linux breaking compatibility. Linux kernel is a moving target, so it is impossible to catch up and get a stable Linux environment. That is why LTS exists: they try to provide a stable Linux. Why? Because Linux is unstable by design.

I dont know which reality you live in, but LTS exists. You should check up why LTS exists and what problem LTS try to solve. Hint: it is not stability.

Reply Score: 4

RE[6]: Comment by Licaon_Kter
by delta0.delta0 on Sun 2nd Apr 2017 20:11 UTC in reply to "RE[5]: Comment by Licaon_Kter"
delta0.delta0 Member since:
2010-06-01

I agree - we should abandon Linux and use a micro-kernel.


Name me 1 pure micro-kernel that can match Linux in performance, name me 1 pure micro-kernel that is used in any major operating system.

The ideas behind micro-kernels are nice their performance has always been an issue. Using userland drivers are essentially what micro-kernels do, its in a ring outside of the core os.

The issue here is simple, Google needs to put its foot down and force hardware vendors that want to supply android hardware to release their drivers as open source software. They should have at least forced this on nexus based devices and should be enforcing this on the pixel based devices now, but Google are Google and for whatever reason they don't.

We have these same debates all the time, the same conclusions are drawn every time and the landscape hasn't changed in the last 20 - 30 years.

I do believe the Linux kernel will eventually get usurped, but by new hardware that shifts design, stuff like the memresistor:

http://electronics360.globalspec.com/article/6389/despite-hp-s-dela...

Even then the kernel can be adapted for such tech because it is and always has been open-sourced.

I don't really understand what problem Google are trying to solve here, but good luck to 'em.

Reply Score: 3

RE[5]: Comment by Licaon_Kter
by MrMIPT on Sun 2nd Apr 2017 15:53 UTC in reply to "RE[4]: Comment by Licaon_Kter"
MrMIPT Member since:
2017-04-01

You have no idea what is Windows driver development and I doubt you have any expertise in Windows kernel.

Windows doesn't have problems with backward compatibility. You still can use old DDK to build drivers for Windows 7 if you do not need new functionality- all definitions and structures are backward compatible.

Reply Score: 1

RE: Comment by Licaon_Kter
by tidux on Sun 2nd Apr 2017 03:52 UTC in reply to "Comment by Licaon_Kter"
tidux Member since:
2011-08-13

The Right Way To Do It is for the chip maintainers to get their code in the mainline kernel. It worked for NICs, it's working for GPUs, it worked for everything in kernelspace on x86 land except for PowerVR and Broadcom being cock-gargling retards as usual. The lack of a stable kernelspace driver ABI is explicitly designed to force people to put their code in the mainline kernel or put the proprietary stuff in userspace (Nvidia) if they want proper long term support for their hardware, and it works. This is just the embedded hardware industry being a bunch of squirrely retards about software as usual.

Reply Score: 6

RE[2]: Comment by Licaon_Kter
by marianne on Sun 2nd Apr 2017 08:24 UTC in reply to "RE: Comment by Licaon_Kter"
marianne Member since:
2013-11-19

Just a minor sidenote, but is "retards" really the best word choice, here? It always sounds at best pretty tacky to use a word that in modern times is a slur against the developmentally disabled. That being said, I thoroughly admire your creativity there. May I suggest the alternative of "cock-gargling cretins"? You can stick far more venom into the sound of "cretin(s)" or "cretinous", and thanks to the euphemism treadmill it actually has the exact same etymology - a word that originally was a medical diagnosis for abnormally low intelligence, then evolved into an insult. But, unlike the word "retard", there's almost certainly very few people still alive who were ever diagnosed a cretin, meaning there's almost no chance of making people outside the cock-garglers you quite rightly take issue with feel insulted by your comment... fantastic, isn't it? ;) Whereas using "retard" means you'll have people like me whining about your word choices. As for myself, I have Asperger's (I'm sure I must be the only OSNews reader to have it), which despite the high intelligence often associated with the condition apparently makes me come under some UN treaty on "the treatment of retarded persons", and that's why the word personally bugs me. Found that lovely bit of trivia out when I was in a "specialist" autistic college where we were generally pretty badly mistreated, with a heavy dollop of patronisation. Apart from your word choice though, I completely agree with your post, closed source drivers have no business being in kernel space!

Reply Score: 3

RE[3]: Comment by Licaon_Kter
by tidux on Mon 3rd Apr 2017 02:15 UTC in reply to "RE[2]: Comment by Licaon_Kter"
tidux Member since:
2011-08-13

> Just a minor sidenote, but is "retards" really the best word choice, here? It always sounds at best pretty tacky to use a word that in modern times is a slur against the developmentally disabled.

That was the exact note I was going for, considering they seem to have a bunch of mentally disabled people in charge of their software development process.

Reply Score: 2

Comment by Sodki
by Sodki on Sat 1st Apr 2017 00:05 UTC
Sodki
Member since:
2005-11-10

My guess? Google is clearly having issues with Android in that it doesn't control the whole stack...


Which bits doesn't Google control? It's a Free Software world, Google can actually control everything downstream, if it wants to. And it does, with its own kernel patches, etc..


... causing Google to be at the whim of chip makers to maintain support for the Linux kernel, leading to the massive problems with Android updates we all know and hate.


The problem is not "controlling the whole stack". The problem is the usage of proprietary drivers. Google is big enough to tip the scales in the other direction, but unfortunately chooses not to - ARM ecosystem could be a lot better at this. There's nothing inherent and exclusive in Fuchsia that can solve this, it's mostly a political issue.

Having said that, there is the issue of the lack of stable kernel interfaces in Linux. If those existed, the same driver could be used on newer versions of the kernel. Linux developers don't want this and I can totally understand why: the code needs to be able to evolve without being artificially stuck in the past. And it's only an issue with proprietary software, so screw it.

Reply Score: 2

RE: Comment by Sodki
by jonsmirl on Sat 1st Apr 2017 02:33 UTC in reply to "Comment by Sodki"
jonsmirl Member since:
2005-07-06

I agree with this assessment of the problem. Google just needs to lay down the law that everything has to go into mainline Linux. Stop the proprietary driver mess.

It is not a lot of work to keep a driver tracking mainline assuming that it has been committed to mainline. That's the key bit -- get it committed to mainline. Based on my work, it is less than an hour a week for a single developer to keep a driver in mainline functioning.

I just gag continuously working on Allwinner code where their engineers did not understand how something worked in the kernel. So instead of asking on LKML they implement some new crazy scheme to work around the issue. If they were required to submit these drivers the maintainers would explain how to use existing solutions in Linux to solve their problems. Instead these crazy solutions get implemented and they become difficult to forward port onto later kernels. The answer here is -- submit your code to mainline!

PS - the Allwinner engineers are not crazy. they come up with these crazy solutions since they work in isolation and can't get feedback.

Edited 2017-04-01 02:34 UTC

Reply Score: 5

RE[2]: Comment by Sodki
by Sodki on Sat 1st Apr 2017 13:05 UTC in reply to "RE: Comment by Sodki"
Sodki Member since:
2005-11-10

It is not a lot of work to keep a driver tracking mainline assuming that it has been committed to mainline. That's the key bit -- get it committed to mainline. Based on my work, it is less than an hour a week for a single developer to keep a driver in mainline functioning.


And it can be even easier than that. If I'm not mistaken, there is a rather large group of upstream Linux developers who will write the drivers for you, free of charge, providing you give them the appropriate documentation. They'll even sign NDAs, if needed. I really don't see the point of keeping it proprietary.

Reply Score: 4

RE[3]: Comment by Sodki
by bassbeast on Sun 2nd Apr 2017 22:56 UTC in reply to "RE[2]: Comment by Sodki"
bassbeast Member since:
2007-11-11

Yeah about that....AMD gave them the specs over 5 years ago, hows that working out for them? Last I heard every Linux site still tells new users to buy Nvidia despite them being so anti-FOSS that Linus actually gave them the finger in the middle of a presentation so my guess is it didn't work out too well for them.

I mean sure its a nice thought and would probably work for something simple like a USB webcam, so seriously complex piece of silicon will billions of transistors? Yeah not so much.

Reply Score: 3

RE[4]: Comment by Sodki
by Sodki on Mon 3rd Apr 2017 20:53 UTC in reply to "RE[3]: Comment by Sodki"
Sodki Member since:
2005-11-10

Yeah about that....AMD gave them the specs over 5 years ago, hows that working out for them?


Not full specs, no. But...

Last I heard every Linux site still tells new users to buy Nvidia despite them being so anti-FOSS that Linus actually gave them the finger in the middle of a presentation so my guess is it didn't work out too well for them.


Only for proprietary drivers. If you're using Free drivers only and you don't have the latest card, then radeon is much better than nouveau. Fortunately nouveau is catching up quickly.

I mean sure its a nice thought and would probably work for something simple like a USB webcam, so seriously complex piece of silicon will billions of transistors? Yeah not so much.


Bollocks. Even AMD and nVidia are contributing to both radeon and nouveau respectively, due to the community's momentum.

Reply Score: 2

Seems like a reasonable idea
by modmans2ndcoming on Sat 1st Apr 2017 01:39 UTC
modmans2ndcoming
Member since:
2005-11-09

The future of productivity is seamless access to your data across modalities (Desktop, laptop, tablet, phone, etc.) ChromeOS isn't cutting it because the application infrastructure isn't there when you compare it to what is available to Android. One OS with one set of applications that can be used across those modalities is what is needed and if they can transition their current suite of applications to that system they will be able to meet the vision that Microsoft is so desperately attempting to provide with Continuum.

Reply Score: 2

RE: Seems like a reasonable idea
by supergear on Sat 1st Apr 2017 07:35 UTC in reply to "Seems like a reasonable idea"
supergear Member since:
2007-07-06

Today is April 1st (April Fools Day)

Reply Score: 2

Megol Member since:
2011-04-11

Today is April 1st (April Fools Day)


Yes but this isn't the announcement of the project nor the first article on it.

Reply Score: 2

bannor99 Member since:
2005-09-15

Today is April 1st (April Fools Day)


True, but the initial release of code was last August

https://en.wikipedia.org/wiki/Google_Fuchsia

But it still sounds crazy to me

Reply Score: 2

RE: Seems like a reasonable idea
by MysterMask on Sun 2nd Apr 2017 06:12 UTC in reply to "Seems like a reasonable idea"
MysterMask Member since:
2005-07-12

Is this a quote of Microsoft marketing? Because seamless access to data does in no way imply the need for the same applications on all "modalities" ..

Reply Score: 2

modmans2ndcoming Member since:
2005-11-09

Sorry, I live in the real world where an application is the data.

Reply Score: 2

Comment by Radio
by Radio on Sat 1st Apr 2017 10:18 UTC
Radio
Member since:
2009-06-20

Fuschia is Google's long play, along with RISC-V or an ARM licence (or close collaboration, like we see with OP1).

Reply Score: 2

RE: Comment by Radio
by kurkosdr on Mon 3rd Apr 2017 12:15 UTC in reply to "Comment by Radio"
kurkosdr Member since:
2011-04-11

Fuschia is Google's long play, along with RISC-V or an ARM licence (or close collaboration, like we see with OP1).


This. Google doesn't want to see a replay of the Windows NT scenario, aka the entire company being stuck with Android and its assumptions (which are going to be obsolete in 8 years) forever.

If Microsoft had started re-writing Windows NT around 2003 or so, there would be no font handling done in the kernel today (so we'd have been spared numerous vulnerabilities) and we wouldn't have Windows hitting the disk so often and using the swap space so heavily, because we don't live in an era of 32MB main memory anymore (unlike the era Windows NT was originally designed for) and those practices are now a liability instead of a benefit.

Edited 2017-04-03 12:17 UTC

Reply Score: 3

Problems with Android
by grat on Sat 1st Apr 2017 16:33 UTC
grat
Member since:
2006-02-02

Been using Android since 2.x series. I've had phones from HP, HTC, Samsung, and now I'm on a Nexus 6P phone and use a Nexus 9 tablet.

I don't actually download that many apps-- I have a core set that I tend to use across my devices.

But Android, especially on the tablet, gets slower, and slower, and slower, and less reliable. My Nexus 9, with Chrome (and no extensions) installed crashes regularly, and is painfully slow to reload.

My previous two tablets went down the same path of gradual entropic failure-- I was hoping a "Google" tablet would be different.

The December security update broke Bluetooth synchronization between my car and my phone-- And Google won't talk to me unless I reset to factory settings to prove their update (the only thing I installed on my phone that month) broke my phone. 7.1.2 might fix it-- but it's held up in development hell, and if I download the beta, I have to wipe my phone to reload the stable release.

I haven't seen an OS that was this unstable since Windows ME.

I know there are tools that will supposedly refresh my ram, and improve performance-- but why am I still reliant on third party tools when I'm running Android 7.x?

Reply Score: 2

RE: Problems with Android
by Necroplasma on Sat 1st Apr 2017 22:47 UTC in reply to "Problems with Android"
Necroplasma Member since:
2013-09-20

I'm sorry but the Nexus 9 is not a good example for Android performance on a tablet. The device was rushed out and they had to disable Android's out of memory management and instead relied on the OOM of the Linux kernel which is pretty aggressive. They also had to fiddle a lot with the Nvidia SoC to get it working somewhat reliably on Android. It was a terrible device. The Pixel C fares a lot better in terms of performance and reliability.

Reply Score: 1

RE[2]: Problems with Android
by darknexus on Mon 3rd Apr 2017 13:00 UTC in reply to "RE: Problems with Android"
darknexus Member since:
2008-07-15

Wow, you Android people are prizes. First you all say that Android isn't crap and really, you should just buy Google devices (Nexus or Pixel). But now, suddenly, the OP's device is not a good example even though it is a Nexus? It's the same old "blame the user" crap I've been seeing from the f/oss community for decades. Pathetic.

Reply Score: 1

RE[3]: Problems with Android
by grat on Mon 3rd Apr 2017 16:30 UTC in reply to "RE[2]: Problems with Android"
grat Member since:
2006-02-02

I wouldn't put it quite that harshly, but, yeah-- the Nexus 9, with Google's version of Android, is supposed to be "The One True Version" of Android-- and if it's crap, that's a problem.

Similarly, if the Chrome browser is widely reviled as crap on Android, and it's supposed to be the flagship browser, that's a problem.

Reply Score: 2

Comment by ssokolow
by ssokolow on Mon 3rd Apr 2017 00:14 UTC
ssokolow
Member since:
2010-01-21

For the record, it's not just FUSE (Filesystems in USErspace) and CUSE (Character devices in USErspace) that Linux offers for userspace drivers.

For example, there's also uinput (an API for user-mode input device drivers) and libusb (which leverages USB's layered design to allow the device-specific code to be written in userland, relying on only the OHCI/UHCI/EHCI/XHCI transport-layer drivers to be in the kernel).

For example, xboxdrv (the more featureful userland alternative to the Linux kernel's XBox controller driver) uses uinput, as does the part of g15daemon which remaps the uselessly non-standard device endpoints for the Logitech G15 keyboard's macro and media keys into something useful.

...and devices like my thermal receipt printer are supported via userland code which sits on top of libusb.

...not to mention userspace drivers being the norm on Linux for printers (CUPS), scanners (SANE), at least one of the IR remotes supported by LIRC, 3DConnexion NDOF pointing devices, front panel LCDs (lcdproc), etc.

Reply Score: 5

Comment by Mukti
by Mukti on Tue 4th Apr 2017 11:26 UTC
Mukti
Member since:
2017-04-04

Maybe Google got tired of "System D" trying to take too much control ...LOL!

OR it could be a UEFI experiment...
"This project contains some experiments in software that runs on UEFI firmware for the purpose of exploring UEFI development and bootloader development."
-https://github.com/fuchsia-mirror/magenta/blob/master/bootloader/REA...

Reply Score: 1