Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuchsia: a new operating system

lwn.net

Post reply on HN
Print view View original

301–310 of 324 posts

Re: Fuchsia: a new operating system

#301

Post by JdeBP »

adrianratnapala wrote: post #47
jlarocco wrote: post #13

Earlier quoted context omitted.

A few days ago somebody posted a link to some very old UNIX documentation from the early 70s. Something that struck me was how similar it was to modern UNIX systems. A lot of abstractions underpinning Linux, the BSDs, and OSX have not changed much in the 45 years since UNIX V1 was developed. It wouldn't hurt to take a fresh look at things. Your argument could have been used against almost every project Google's worke…

Of course that's largely because those abstractions were good ones. Someone in a comment above noted that Rob Pike thinks Unix is obsolete. But then he was probably thinking about Plan9 which was indeed better than UNIX -- because it even more unixy. Filesystems all the way down. Capabilities are the first new abstraction I have heard of that really go beyond the Unix model.

You need to read more. A lot more. (-:

For starters, read the headlined article that observes that capabilities pre-date the UNIX model.

Even the "classic authorities" on this stuff, including Bach, Comer, Deitel, and Tanenbaum, pointed to many things that went beyond the UNIX model. And this was almost thirty years ago.

There is a wealth of experimentation and diversity that already exists and that has been done over the intervening many years. In addition to the operating systems already mentioned on this very page, there's Helios which was a capability-based system with a POSIX layer on top from the late 1980s/early 1990s. The BSD 4.4 Log-Structured Filesystem had global wear levelling in the filesystem in 1990. OS/2 1.0 went beyond terminal escape codes and multiple mouse protocols to a device-neutral video, keyboard, and mouse paradigm for TUI applications in 1987. People have done operating systems where everything really is a file, "object oriented" operating systems, network distributed operating systems, microkernel operating systems with multiple "personalities", ... all sorts.

Re: Fuchsia: a new operating system

#302

Post by pjmlp »

nickpsecurity wrote: post #272
pjmlp wrote: post #218

Earlier quoted context omitted.

To be fair, if Frama-C is an option, as someone on the C++ side of the fence (C vs C++) I would advocate High Integrity C++ is also an option. :) http://www.ldra.com/en/software-quality-test-tools/group/by-...

I thought about it. The reason I left it off is a lack of static analysis, automatic generation of tests, certified compilers, etc. There's tons of FOSS and commercial vendors for doing such things in C with quite a bit for Ada. Whereas, I could find only one or two products for C++ that seemed like it would be really helpful as opposed to just kind of. So, I pivoted my recommendations to go with languages that have…

I guess so, I just know it from reading about it, so it might be that when using it won't be as suitable as I think it could be.

On the Java side you can probably check what Aonix used to do, they are now part of PTC.

http://www.ptc.com/developer-tools/perc

Also there are the guys from MicroEJ.

http://www.microej.com/products/device-software-development/...

There is no Oracle risk with Java, when companies play by the rules.

PTC, Aicas, IBM, MicroEJ, Excelcior JET, HP, Cisco, Ricoh, Azul, Red Hat and so many other companies are selling JDKs with their own set of features, without having had any issue with Sun or Oracle.

Only Google has an issue with Oracle, because they decided they were the cool kid better than anyone else whose rules don't apply to.

Re: Fuchsia: a new operating system

#303

Post by pjmlp »

michaelmrose wrote: post #284
pjmlp wrote: post #238

Earlier quoted context omitted.

You mean like package formats, audio subsystems, configuration files that didn't exist on original UNIX, window managers, init systems, ...

Lets start with package formats, people discuss this matter as if it were building an app for ios vs android. 99.999% of the work is the application. Package formats are just different sets of instructions for building the same source code the works ultimately on any system so long as its required libraries are present. Continuing on with audio, virtually everyone uses pulseaudio. JACK is pretty much reserved for aud…

No, package formats aren't just different sets of instructions, because on each distribution certain files might land on different places.

Plus someone has to keep track of those instructions for every single distribution.

Finally, supporting the same format isn't enough, for example a RPM for SuSE isn't the same as a RPM for Red-Hat.

Well, apparently you forgot there are people still using ALSA and OSS.

When doing desktop applications anyone that cares about UI/UX of the respective users wants to integrate with the menu system, notification on the toolbar, context menus, drag-and-drop of the window manager, printing,....

So it isn't just components.

Of course, if the goal is to have a plain twm experience, then forget about what I am saying.

Re: Fuchsia: a new operating system

#304

Post by monocasa »

rwmj wrote: post #136
makomk wrote: post #110

Earlier quoted context omitted.

Having control over the virtual to physical address mapping and scatter-gather lists for GPUs is effectively equivalent to kernel-level access anyway, though, because it lets you carry out DMA to and from arbitrary physical memory addresses. Some proprietary drivers for mobile GPUs have even given this level of access to untrusted user processes in the past leading to privilege escalation to root.

Not with IOMMU (Intel VT-d and similar).

And GPUs these days have their own MMUs too.

Re: Fuchsia: a new operating system

#305

Post by monocasa »

rayiner wrote: post #52
desdiv wrote: post #39

Earlier quoted context omitted.

>They are drawing everything in userspace with fast graphics render... Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?

What happens these days is that GPU buffers are mapped into user space, where they are filled with textures and drawing commands. Then, they are submitted to the kernel GPU scheduler for execution. See e.g. https://lwn.net/Articles/283798 .

These days you don't even submit them via a kernel call these days; you've got your own GPU MMU context so you can kind of just go to town within your own process.

That's sort of the whole point behind Mantle/Vulkan/Metal/DX12.

Re: Fuchsia: a new operating system

#306

Post by monocasa »

deaddodo wrote: post #135
desdiv wrote: post #39

Earlier quoted context omitted.

>They are drawing everything in userspace with fast graphics render... Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?

Depends on the OS design. It's really not a good design, but you could run everything in ring0 (x86), supervisor mode (ARM), etc. However, now any fault (user or OS) could halt your system and you have no memory protection or process separation.

You've also have Singularity style software isolated processes where the OS statically verifies memory safety so that it can safely run all of the code in ring 0.

Re: Fuchsia: a new operating system

#307

Post by milcron »

bostik wrote: post #267
milcron wrote: post #154

Earlier quoted context omitted.

Individually, computers today are more secure than they've ever been. But there are zillions more computers, doing more things, with more interconnections than ever before. So the problems are compounded and I think the situation is worse overall.

> * Individually, computers today are more secure than they've ever been.* Unfortunately, that only holds if you take the view that IoT appliance != computer. Because let's be honest - those things are dangerous to general network hygiene and wellbeing.

True, IoT devices are less secure than their internetless predecessors. But they're more secure than Windows 95 computers.

Re: Fuchsia: a new operating system

#308

Post by snvzz »

throwayedidqo wrote: post #276
gkya wrote: post #250

Earlier quoted context omitted.

This is a complete misunderstanding/misrepresentation of what a microkernel is. Even GNU is developing their own microkernel, the HURD.

I may be overly paranoid, but the majority of what Fuscia is trying to accomplish is extremely bad for open platforms. The outcome of moving drivers to user space will be proliferation of binary blobs and black box drivers. If you think binary GPU drivers are bad now, imagine an "open source" OS where every single driver is a binary blob. It will become impossible to run Fuscia devices on any other operating system b…

>If you think binary GPU drivers are bad now, imagine an "open source" OS where every single driver is a binary blob.

The current situation is they're tied to a version of the kernel, and typically abandoned by the vendors. With userspace drivers and driver APIs, the "android upgrade problem" would be solved.

It'd then be a matter of reversing these drivers, which should be far easier when they're running in userspace and completely bounded.

Re: Fuchsia: a new operating system

#309

Post by jasonvorhe »

milesrout wrote: post #199
cozicoolmail wrote: post #156

Earlier quoted context omitted.

Who does that leave to help with your OS? Apple? Their support is pretty bad too.

What about, the people that made it in the first place? The support I've had from companies like Red Hat is unparalleled .

If you pay a monthly subscription.

Re: Fuchsia: a new operating system

#310

Post by staticassertion »

pinealservo wrote: post #289
staticassertion wrote: post #155

Earlier quoted context omitted.

I wouldn't use SEL4 as an argument. It is completely unreasonable to build a production kernel the way they did - it took them ages to get what they had. Google is probably looking to develop features/ move code a lot faster than is possible using their technique. Good coding practices take no time to implement, you learn it once and you write that way. It is not bullet proof, neither are capabilities. Still, at leas…

I think you miss the point of a microkernel! The point is to keep all your "features" outside of it, and to use it only to implement the core set of functionality necessary to have secure shared access to the hardware. The general L4 concept has proven industry use, so there's no reason you can't take advantage of the already accomplished work on seL4 to bootstrap your own secure OS. It's true that seL4 is not a magi…

I didn't realize you were recommending to use sel4, I assumed you meant they should have proven theirs using similar methods.
Post reply on HN