![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
a few insights i've had recently:
---
potential platform-specific primitives such as modular-addition-with-carry-and-overflow will probably be implemented in the std library in terms of arbitrary-precision addition; but then implementations will override these with platform-specific calls. To generalize this, a user should be able to override any accessible library function with their own FFI implementation.
---
" Decision 3: Kick RDF in the Nuts
RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! The key data structure that’s used by almost every programmer on this planet and RDF starts out by giving developers a big fat middle finger in that area. Blank nodes are an abomination that we need, but they are applied inconsistently in the RDF data model (you can use them in some places, but not others). When we started with JSON-LD, RDF didn’t have native graph support either. For all the “RDF data model is elegant” arguments we’ve seen over the past decade, there are just as many reasons to kick it to the curb. This is exactly what we did when we created JSON-LD, and that really pissed off a number of people that had been working on RDF for over a decade.
I personally wanted JSON-LD to be compatible with RDF, but that’s about it. You could convert JSON-LD to and from RDF and get something useful, but JSON-LD had a more sane data model where lists were a first-class construct, you had generalized graphs, and you could use JSON-LD using a simple library and standard JSON tooling. To put that in perspective, to work with RDF you typically needed a quad store, a SPARQL engine, and some hefty libraries. Your standard web developer has no interest in that toolchain because it adds more complexity to the solution than is necessary.
So screw it, we thought, let’s create a graph data model that looks and feels like JSON, RDF and the Semantic Web be damned. That’s exactly what we did and it was working out pretty well until…
...
That said, after 7+ years of being involved with Semantic Web / Linked Data, our company has never had a need for a quad store, RDF/XML, N3, NTriples, TURTLE, or SPARQL. When you chair standards groups that kick out “Semantic Web” standards, but even your company can’t stomach the technologies involved, something is wrong. That’s why my personal approach with JSON-LD just happened to be burning most of the Semantic Web technology stack (TURTLE/SPARQL/Quad Stores) to the ground and starting over. It’s not a strategy that works for everyone, but it’s the only one that worked for us, and the only way we could think of jarring the more traditional Semantic Web community out of its complacency. "
---
http://www.w3.org/TR/json-ld/#basic-concepts
http://json-ld.org/playground/
---
" Many of the designs for these stack computers have their roots in the Forth programming language. This is because Forth forms both a high level and assembly language for a stack machine that has two hardware stacks: one for expression evaluation/parameter passing, and one for return addresses. In a sense, the Forth language actually defines a stack based computer architecture which is emulated by the host processor while executing Forth programs. The similarities between this language and the hardware designs is not an accident. Members of the current generation of stack machines have without exception been designed and promoted by people with Forth programming backgrounds. " -- http://users.ece.cmu.edu/~koopman/stack_computers/sec1_5.html (1989)
---
"Lua is much much simpler than Javascript, which is again simpler than Python (Python is really vast)." -- https://news.ycombinator.com/item?id=5310186
"I've been working on a range of JIT compilers, but the PyPy? is the biggest one. The problem is ... that interaction between (semantics) is a headache... descriptors, metaclassses, new/old style classes, tons of builtin types, tons of builtin modules, all of it the user will expect to seamlessly integrate with the JIT compiler." -- https://news.ycombinator.com/item?id=5331454
---
evincarofautumn 551 days ago
| link |
I develop a compiler for ActionScript? 3. Though it’s not a great language, it does have a few distinct advantages over its cousin JavaScript?. First, type annotations. Obviously the more knowledge you have about the structure of the program, the better you can help it run well. Having a class model instead of a prototype model also helps—much as I like working with prototypes—because you can easily eliminate late binding (“hash lookups”) and allocations, two of the performance killers mentioned in the slides. The operative word there is easily. You can analyse and JIT all you want, but you cannot feasibly solve at runtime the fundamental constraints imposed by the language.
Say a compiler author needs twice as much effort and cleverness to make programs in language X run fast than for language Y. That means that—all other things being equal—implementations of X will be twice as slow as Y for the same basic quality of implementation.
---
"This function handles sensitive information, and the compiler must ensure that upon return all system state which has been used implicitly by the function has been sanitized."
While I am not a compiler developer, I don't think this is an entirely unreasonable feature request: Ensuring that registers are sanitized can be done via existing support for calling conventions by declaring that every register is callee-save, and sanitizing the stack should be easy given that that compiler knows precisely how much space it has allocated.
With such a feature added to the C language, it will finally be possible — in combination with memset_s from C11 — to write code which obtains cryptographic keys, uses them without leaking them into other parts of the system state, and then wipes them from memory so that a future system compromise can't reveal the keys. People talk a lot about forward secrecy; it's time to do something about it.
pslam 19 hours ago
| link |
Part 2 is correct in that trying to zero memory to "cover your tracks" is an indication that You're Doing It Wrong, but I disagree that this is a language issue.
Even if you hand-wrote some assembly, carefully managing where data is stored, wiping registers after use, you still end up information leakage. Typically the CPU cache hierarchy is going to end up with some copies of keys and plaintext. You know that? OK, then did you know that typically a "cache invalidate" operation doesn't actually zero its data SRAMs, and just resets the tag SRAMs? There are instructions on most platforms to read these back (if you're at the right privilege level). Timing attacks are also possible unless you hand-wrote that assembly knowing exactly which platform it's going to run on. Intel et al have a habit of making things like multiply-add have a "fast path" depending on the input values, so you end up leaking the magnitude of inputs.
Leaving aside timing attacks (which are just an algorithm and instruction selection problem), the right solution is isolation. Often people go for physical isolation: hardware security modules (HSMs). A much less expensive solution is sandboxing: stick these functions in their own process, with a thin channel of communication. If you want to blow away all its state, then wipe every page that was allocated to it.
Trying to tackle this without platform support is futile. Even if you have language support. I've always frowned at attempts to make userland crypto libraries "cover their tracks" because it's an attempt to protect a process from itself. That engineering effort would have been better spent making some actual, hardware supported separation, such as process isolation.
reply
acqq 1 hour ago
| link |
The "right privilege level" allows you to see anything that happens during the execution of the lower privilege levels. I can even single-step your application with the right privilege level. So the crypto services have to run at the high privilege level and ideally your applications should leave even the key management to the "higher privilege levels." That way attacking the application can leak the data, but not the key, that is, you can still have the "perfect forward secrecy" from the point of the view of the application. So you have to trust the OS and the hardware and implement all the tricky things on that level. Trying to solve anything like that on the language level doesn't seem to be the right direction of the attacking the problem.
reply
tgflynn 15 hours ago
| link |
So is it correct to say that if a process does not want to leak information to other processes with different user ID's running under the same kernel that a necessary (but not necessarily sufficient, due to things like timing attacks) condition is for it to ensure that any allocated memory is zero'd before being free'd ?
I wonder if current VM implementations are doing this systematically.
It seems like a kernel API to request "secure" memory and then have the kernel ensure zeroing would be useful. Without this I'm wondering if it's even possible for a process to ensure that physical memory is zero'd, since it can only work with virtual memory.
reply
pslam 12 hours ago
| link |
All kernels I know of zero all memory they hand over to user processes. It's been part of basic security for quite some time - exactly for this kind of thing. It's usually done on allocation, not free - it doesn't really matter which way around, but doing it "lazily" can often be better performance.
reply
---
told phill about my Views idea. His feeling was that's it's useless b/c you can do the same thing with multiple inheritance. I'm not sure if there is anything views can do that multiple inheritance can't, i'm still thinking about that. If not, then my arguments are:
---
next-gen systems that people mention/that i've heard of:
https://news.ycombinator.com/item?id=8324578
inferno, plan 9, minix, "Oberon variants, specially System 3 release with its gadgets.", Amoeba
---
sergiosgc 1 day ago
| link |
> I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
I tend to simplistically reduce this choice between:
Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Unix ecosystems are more alive; it is easier to replace system parts and create operating systems out of your own choice of replaceable layers. The monolithic nature of Windows is a reflection on the failure of the object oriented approach to operating system interfaces.
Mind you, I don't think it is an intrinsic fault. It may be that it's a fault of this implementation of an OO operating system.
This is the main reason I dislike what the Gnome folks are pushing down Linux's throat. The Gnome way is, today, at odds with the Unix way.
reply
fragmede 1 day ago
| link |
That's an over-simplification, as when you get down to it, there are plenty of things that don't use the file API on UNIX, or at least have convenient wrappers so you're not blindly calling 'ioctl' left and right. I'm thinking specifically of the socket API for bind/connect/accept, the inotify interface, with inotify_* functions, the (less commonly used these days) serial port API, with the tc* and cf* functions.
> It may be that it's a fault of this implementation of an OO operating system.
I'm not convinced it's just this implementation. When everything's an object, there's additional overhead as a programmer trying to use the API.
File based API - Open a file using the same 'open' call you've always used, and then call 'read' or 'write' (or even 'ioctl') on the file descriptor. Call 'close' when done. There may be multiple files you need to access to get the particular behavior you want.
Object based API - Browse around the docs until you find that particular subsystem's API. Read a bunch. Finally instantiate the object you need. Set all of the objects various properties. Call CreateObject?(object, options). Wait, go back and create a options object. Set all of the properties on that object as well. Try that until you figure out you needed to call CreateObjectEx? instead. Hit your head on the desk for a couple hours until you figure out that you also need to call RunObject?, and that one of the parameters on the options object was set wrong.
As a programmer, the file-based API is just a layer of indirection to make things easier, and shouldn't be considered a limiting factor.
Then again, there's this article about Event Tracing on Windows, that makes me think it's just this iteration of OO-based operating system, and a better designed API would do us all a favor.
http://mollyrocket.com/casey/stream_0029.html
reply
taeric 1 day ago
| link |
That is more easily reduced to
That is, the "object" way sounds more promising and unlimited. I think, in practice, it is that unlimited nature that actually hurts.
Though, I hate the "paradox of choice" and I think I am saying it reduces to that. :(
reply
jude- 1 day ago
| link |
I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Specifically, file operations already represent:
I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.
reply
pjmlp 1 day ago
| link |
> Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results.
Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.
reply
ahomescu1 23 hours ago
| link |
> - Everything is an object (the windows way)
I wouldn't say there is a "Windows way", considering that current Windows is actually a system composed of several different layered components:
1) The NT kernel (which is pretty nicely designed) its own ideas of what "objects" are and all the ObXXX? functions.
2) Win32 which is a horrible mess from the Windows 3.1 days and maybe earlier.
3) COM and flavors, which actually came later with its own brand of objects.
4) The .NET framework.
It doesn't seem to me that "Windows objects" are really unified in spirit and design across all these components (not to mention that Win32 isn't object-oriented at all).
reply
metafex 1 day ago
| link |
> Yes, UNIX has a bunch of nice ideas, but that is all. Ouch, that actually hurts a little. Yes, the kernel team at Microsoft is the real deal, but I'll not go into that.
As to "a bunch of nice ideas", I'd suggest you take a look at the concepts that Plan 9 from Bell Labs brings to the table. The everything is a file concept there is something I wish would have taken over the more classic approach to devices, networking, etc. Want to open a remote shell on another server? Easy as opening a file handle. Accessing the CPU and running programs? Same story. Now if you call that just a nice idea, I rest my case ;-)
Microsoft even explored some of those concepts in their research OSes like Singularity and Midori. There has to be something about those ideas that they appeal even to MS, that's just my view though.
reply
pjmlp 1 day ago
| link |
Quoting Rob Pike on his Slashdot interview:
We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
reply
jacquesm 1 day ago
| link |
I think the main reason why 'everything is a file' is so powerful is because it comes with a built in security model.
reply
pjmlp 1 day ago
| link |
Plan 9 != UNIX
reply
metafex 1 day ago
| link |
Yeah, I know, it's the unix concept thought further :)
reply
gillianseed 1 day ago
| link |
>I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
What is Windows doing differently than UNIX monolithic kernels? Drivers and filesystems run in NT kernel space.
reply
pjmlp 1 day ago
| link |
reply
gillianseed 6 hours ago
| link |
>Moving their kernel to C++
Not sure this matters given the extreme low-level nature of kernel and driver coding. Certainly not enough to warrant a rewrite, which I guess is a result of Microsoft more or less dropping support for modern C in their compiler by not even supporting C99 fully.
>Experimenting with new OS architectures
Certainly Singularity was an interesting experiment, sadly and typical of Microsoft mentality, once they ruled it out for production use and passed it off for others to play with, they chose to do so under such a restrictive license (shared source) that no one will do something interesting with it.
As for drawbridge, the same ideas regarding sandboxing are being worked on in the Linux camp, and from what I understand also in solutions like Capsicum on FreeBSD?, from the looks of it, *NIX is way ahead of Microsoft in this area.
>Continue the multimedia OS culture of Atari ST, Amiga systems
Not sure what you mean here unless you are talking about coming with a GUI out-of-the-box ?
Your typical current Linux distro is more of a 'multimedia OS' than Atari ST or Amiga ever was (owned them both), which includes BeOS?