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

21–30 of 60 posts

Re: What I wish systems researchers would work on

#21

Post by pi18n »

qznc wrote: post #19
lmm wrote: post #7

Earlier quoted context omitted.

Using a standardized, real programming language (TCL) as a standard for configuration files was suggested something like 15 years ago. RMS shot it down, saying the GNU would never use it, that they would build their own format that all the GNU tools would use (which IIRC never materialized). The problem isn't creating a good language, it's persuading the linux community to standardize on something.

Well, TCL is not a good language for configuration files imho. I'd favor a declarative approach, because you can analyse (hence debug, check, etc) it better. Inspired by Prolog, but change the syntax. A configuration language should also avoid features like "eval", though Turing-completeness is probably desirable. Nevertheless I agree that standardization is a problem. Not for the "linux community", but in general. S…

Turing completeness is maybe not desirable... look at what happened when YAML was allowed to create objects of any class it liked.

I like your declarative language idea very much, though. As long as it cannot execute arbitrary code.

Re: What I wish systems researchers would work on

#22

Post by pi18n »

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…

This sounds interesting! Have you published anything more substantial on it? I yearn for the day when I can have a Plan 9-ish resource sharing and file system connecting my personal computer to my cloud computers.

Re: What I wish systems researchers would work on

#23

Post by pjmlp »

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?

By being written in systems programming languages safer than C.

Re: What I wish systems researchers would work on

#24

Post by tomp »

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…

While reading your comment, I thought of the problems with configuration files I was having in my own project... when I realized, "why not just use python"?

The program (written in go) could simply launch a new process on startup, e.g.

  python -c "import imp; c = imp.load_source('c', 'abc.conf'); print '\n'.join('%s = %s' % (n, repr(getattr(c, n))) for n in ['option1', 'option2', 'option3'])"
and read it's output (which could also be another well-known format, like JSON) and use it for configuration. Simple, elegant, and enables very powerful abstractions.

Re: What I wish systems researchers would work on

#25

Post by nostrademons »

graycat wrote: post #11

In the OP, the > The "bug" here was not a software bug, or even a bad configuration: it was the unexpected interaction between two very different (and independently-maintained) software systems leading to a new mode of resource exhaustion. can be viewed as pointing to the solution: Broadly in computing, we have 'resource limits' from the largest integer that can be stored in 2's complement in 32 bits to disk partitio…

All of this is done at Google - there's extensive monitoring for all production systems, with alerts firing once parameters move outside of their statistical "normal" range. In practice the range tends to get set more by "How tight can we make it before we get really annoyed by these pagers?" than any rigorous statistical method, but the run-time operation carefully measures average & extreme values and determines when a spike is just a momentary anomaly vs. when it's worth paging someone.

The problem is that inevitably the next problem is exhaustion of some resource that nobody even thought of as a resource. In my time at Google, some of the resource limits I've faced have included (besides the obvious RAM/disk/CPU): binary size, size of linker inputs, average screen size of websearch users, time required for an AJAX request, byte-size of the search results page, visual space on the monitoring UI, size of a Javascript alert box, maximum length of a URL in Internet Explorer, maximum length of a request in Google's load-balancers, time until someone submits a CL touching the same config file as you, and time before a cosmic ray causes a single-bit error in memory.

File descriptors are a comparatively obvious resource, but nobody thought of them because in previous normal operation they never even came close to running out. Should someone set an alert on "wind speed running through the Columbia River Gorge" (which would've been responsible for an actual outage had there not been significant redundancy in the system, BTW)?

Re: What I wish systems researchers would work on

#26

Post by InclinedPlane »

Configuration, performance, package management, reliability/robustness, security, monitoring, virtualization, and distributed computing. Those are the big problems and missing pieces that people doing systems level engineering are facing today. And, no coincidence, these are the things where you see the most repeated instances of tools that address these issues.

Consider package management. You have an OS level package manager, you have OS level application management (on android, for example), you have node package management, you have ruby gems, you have perl and python packages, you have wordpress themes and plugins, etc. Obviously it doesn't make sense to have a single global package manager, but what about standards for package management? Competing package management infrastructures which serve as foundations for all these lower level systems? A mechanism for aggregating information and control for all of the package management sub-systems?

As the article points out a lot of systems folks and OS folks are still retreading the same paths. They want to pave those paths, then build moving walkways, and so forth. That's all fine and good, but there's a lot of wilderness out there, and a lot of people are out in that wilderness hacking away with machetes and pickaxes building settlements, but for some reason most OS folks don't even imagine that roads can go there too.

Re: What I wish systems researchers would work on

#27

Post by InclinedPlane »

codex wrote: post #8
jacques_chester wrote: post #2

Computer systems, which are deterministic , have long since passed out of the realm of being understandable . They're chaotic systems[1]. Parameters which are below the threshold of detection can drastically affect their trajectory in phase space. Accidental complexity has zoomed off to live a life all its own, and that takeoff has been continuous for decades [2]. Everything we build around software that's not direct…

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.

Re: What I wish systems researchers would work on

#28

Post by regularfry »

InclinedPlane wrote: post #26

Configuration, performance, package management, reliability/robustness, security, monitoring, virtualization, and distributed computing. Those are the big problems and missing pieces that people doing systems level engineering are facing today. And, no coincidence, these are the things where you see the most repeated instances of tools that address these issues. Consider package management. You have an OS level packa…

As far as the ruby/python/perl package problem goes, I think we're heading towards a standard with virtualenv-style tools and potted environments. The simplest possible standard there is a /bin/activate script to set the right environment variables; you can build pretty much anything else you want on top of that.

Re: What I wish systems researchers would work on

#29

Post by rwmj »

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/

Re: What I wish systems researchers would work on

#30

Post by dasil003 »

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…

> This means that the config files behave nothing like actual software--instead, they have their own special rules to follow and their own semantics to understand. These languages also tend to have very little abstractive power, which leads to all sort of incidental complexity and redundancy. Good software engineering and programming language practices are simply thrown away in config files.

I have to disagree that this is the critical problem with system configuration. The typical config has orders of magnitude less complexity than the typical software project. The problem with config files is not the complexity of the configuration itself (except perhaps in Java), but the complexity of the global effects they produce. It doesn't matter how clean and DRY you make your config, and how well-tested, if the software supports too many options that can interact in unpredictable ways, or worse, produce subtle outward facing changes that ripple out to systems that interact with yours.

Post reply on HN