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

What I wish systems researchers would work on

matt-welsh.blogspot.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: What I wish systems researchers would work on

#51

Post by david927 »

graycat wrote: post #44
david927 wrote: post #39

Earlier quoted context omitted.

It's a great comment, graycat, and I couldn't agree more. Where we might differ is that I think the future of computing is in Computer Science -- but where it will lead to an extension of mathematics (specifically Set Theory). But we're essentially saying the same thing.

For where computing will be based, currently there are big cultural issues: With one paper I published, in a computer science journal for a problem in computer science but basically some applied math, I had to discover that, really, it was tough for the computer science community to review the paper. I sent an 'informal' submission to a nice list of the top journals appropriate for the paper. From one Editor in Chief…

Wow... That's a tremendous response. Thank you.

Could you please send me links to everything you have ever written? Please. My email is in my profile.

Re: What I wish systems researchers would work on

#52

Post by fizx »

rwmj wrote: post #29
tikhonj wrote: post #6

Dealing with configuration files is a problem that extends well beyond distributed systems, or even systems programming in general. It's certainly a very important issue. One of the fundamental problems with configuration files is that they are written in ad-hoc external DSLs. This means that the config files behave nothing like actual software--instead, they have their own special rules to follow and their own seman…

You really don't want to use a Turing-complete language for configuration. It makes all sorts of things impossible such as: - Automatically scanning for insecure configurations (eg. OpenSCAP) - Parsing the configuration in other programs. - Modifying the configuration programmatically (cf. Puppet et al) Also, http://augeas.net/

On the off chance you see this later, I think you want a Turing-complete language, but one without an interesting standard library.

> - Automatically scanning for insecure configurations (eg. OpenSCAP)

Since the language can't access the outside world, the worst it can do is use unbounded space or time. Just verify that it halts in a couple ms.

> - Parsing the configuration in other programs.

You don't parse, you embed an interpreter and execute.

> - Modifying the configuration programmatically (cf. Puppet et al)

Code generation isn't that hard.

Re: What I wish systems researchers would work on

#53

Post by fizx »

graycat wrote: post #15
ethereal wrote: post #4

Earlier quoted context omitted.

Just reading your second reference, the bit about expert systems is pretty interesting . . . what's your stance on this? It seems that, given sufficient instrumentation information, one could probably construct a fairly decent expert system that might be able to shed some light onto these sorts of problems. (Keep in mind the fact that I'm still very much a junior software developer!) The example of FDs from the origi…

Expert systems for monitoring and management of large server farms and networks? Been there. Done that. Got the T-shirt. Wrote papers. Gave one at an AAAI IAAI conference at Stanford. Shipped two commercial products. First problem: Need some 'experts'. So, only know about problems the experts do. Their knowledge is supposed to be mostly just empirical, from their 'expert experience'. Even if they have 'deep knowledge…

Would love to get an email (address in profile) from you to chat about some tangental stuff (re: intelligence in monitoring systems)

Re: What I wish systems researchers would work on

#54

Post by verma7 »

ethereal wrote: post #3

Speaking as a student studying systems (particularly security and OS development) . . . the second point sounds really interesting. Recently I've been working on a simple microkernel (called Sydi) that should actually make this possible. It's a distributed system straight down to the kernel: when two instances of the kernel detect each other running on a network, they freely swap processes and resources between each…

> It would be expensive -- requiring a freeze of all running processes while the snapshot is taking place to maintain any level of precision.

Have you thought about distributed algorithms like the Chandy-Lamport Snapshot algorithm (http://en.wikipedia.org/wiki/Snapshot_algorithm) that take a consistent snapshot and do not require a system freeze?

Re: What I wish systems researchers would work on

#55

Post by graycat »

david927 wrote: post #51
graycat wrote: post #44

Earlier quoted context omitted.

For where computing will be based, currently there are big cultural issues: With one paper I published, in a computer science journal for a problem in computer science but basically some applied math, I had to discover that, really, it was tough for the computer science community to review the paper. I sent an 'informal' submission to a nice list of the top journals appropriate for the paper. From one Editor in Chief…

Wow... That's a tremendous response. Thank you. Could you please send me links to everything you have ever written? Please. My email is in my profile.

All praise is welcome!

For now I'm anonymous at Hacker News.

Sorry.

Re: What I wish systems researchers would work on

#56

Post by eli_gottlieb »

pjmlp wrote: post #23
qznc wrote: post #20

Earlier quoted context omitted.

Well, there is a lot of interest in a secure, scalable, fast, deterministic, simple OS which is also backwards compatible. ;) What do you mean by "safe" though? How is kernel-space safer then user-space?

By being written in systems programming languages safer than C.

That would require building consensus around such a language. I mean, yes, this is one of my own hobby projects, but Rust is the most fully-developed attempt made so far and it still doesn't have the kind of developer backing that C did in the BSD days.

Re: What I wish systems researchers would work on

#57

Post by slacka »

InclinedPlane wrote: post #27
codex wrote: post #8

Earlier quoted context omitted.

They're not even deterministic. Even if your input is totally ordered, entropy from the memory subsystem will bubble up to communicating threads if you have more than one. Sometimes one thread will read the newly written value, sometimes the old. That said, there is some clever research out of UW into how to make such systems deterministic while still recovering almost all parallelism.

I think the more important point jacques_chester was making is that even in the case where computer systems are 100% deterministic it doesn't matter because they are so complex they become chaotic systems. And then hypothetical determinism won't save you because there are too many variables in play simultaneously, and even the slightest variation in any one of them could change the behavior completely.

Sorry guys, but I don't buy your defeatist arguments for one second. Sure using traditional tools, you may be right. However, all we have to do is look at the brain with its 100 trillion Connections (axioms) or a CPU with its billions of transistors to see that your logic is flawed. If it was not possible to design fault tolerant systems on large scale neither of these two examples could exist.

I don't claim to have the answers, but a few years ago, I had to help out some EE's write some testing software in LabVIEW. The first thing that shocked me was the system was immune to bad data. Secondly, how elegantly it took advantage of our multiprocessing and multithreading hardware.

What I wish systems researchers would work on is concurrent, signal-based, synchronous languages. This is a winnable game, but we must swallow the red pill and change the rules of the game with new tools and fresh ideas.

Re: What I wish systems researchers would work on

#58

Post by pjmlp »

eli_gottlieb wrote: post #56
pjmlp wrote: post #23

Earlier quoted context omitted.

By being written in systems programming languages safer than C.

That would require building consensus around such a language. I mean, yes, this is one of my own hobby projects, but Rust is the most fully-developed attempt made so far and it still doesn't have the kind of developer backing that C did in the BSD days.

I am old enough to remember when C only had backing from people working on UNIX systems, while other systems were either using Assembly or another high level language e.g. PL/I, Algol or Pascal dialect.

Re: What I wish systems researchers would work on

#59

Post by zobzu »

qznc wrote: post #20
zobzu wrote: post #5

i find it "interesting" that all the complains are about useability from a "userland" developer pov. Generally what comes from that are patched up systems to "run stuff in kernel" because "its safe and fast" Which of course is not true. There are however various attempts to make a "proper" "modern" OS but all of these have failed due to the lack of commercial backing. There is apparently no financial interest into ha…

Well, there is a lot of interest in a secure, scalable, fast, deterministic, simple OS which is also backwards compatible. ;) What do you mean by "safe" though? How is kernel-space safer then user-space?

Note that the part where I mentioned kernel and safe used quotes because its sarcastic.

The modern oses do have kernels that are much safer than what we use day to day, however. They're indeed not in C. In general the core is typed ASM and it runs a a managed language right on top. The kernel is generally written with that and uses various concepts that separate privileges as much as possible for security, reliability and predictability, basically. That includes kernel components, and obviously drivers. Messages between components are also generally declared ("contracted") with well defined types.

Re: What I wish systems researchers would work on

#60

Post by zobzu »

pjmlp wrote: post #10
zobzu wrote: post #5

i find it "interesting" that all the complains are about useability from a "userland" developer pov. Generally what comes from that are patched up systems to "run stuff in kernel" because "its safe and fast" Which of course is not true. There are however various attempts to make a "proper" "modern" OS but all of these have failed due to the lack of commercial backing. There is apparently no financial interest into ha…

They haven't given up yet. The Mindori project is still secret, so who knows what they are doing there, while some of the team is nowadays playing with the concept of pico-hipervisors and running the full OS as a library instead. http://research.microsoft.com/en-us/projects/drawbridge/

I somehow hadn't noticed it, even thus its not new. Thanks :)
Post reply on HN