> There's plenty of gray area ...
There's not. Journalism and politics have this covered:
NO GIFTS.
It's really that simple.
1,974 karma · joined December 1, 2013
There's not. Journalism and politics have this covered:
NO GIFTS.
It's really that simple.
That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
You've seen where their OS code comes from, and what it's written in, right?
Just to be very clear, I'm very well-versed in life outside C and imperative programming. This isn't "UNIX culture". This is "systems programming" culture, and it's simply pragmatic.
Seriously this.
I write an awful lot of kernel code. There's absolutely no way I'd try to convince folks to accept Rust code into the OS repository, where it will have to:
- Be maintained for decades
- Be ported to a litany of platforms, several of which may only have decent toolchains from the GCC department.
- Vend stable ABI
- Not require keeping a litany of compiler versions around just to keep older code building.
Review the "Breaking Changes" of release notes, and the number of discussions regarding removing API after a short (in the view of someone who works on said "systems code") period of deprecation.
> Besides, this is completely off topic in a Zig thread. From the FAQ: "Zig is not afraid to roll the major version number of the language if it improves simplicity, fixes poor design decisions, or adds a new feature which compromises backward compatibility."
And thus, it won't be used as a systems language.
In terms of ABI stability, Rust has none.
In terms of API stability, they seem willing to drop features within a major release cycle or two.
In terms of language stability, they seem to only guarantee stability within one major release (e.g. 1.x).
Rewriting for the sake of language updates is a huge resource drain when you're talking about code bases with lifetimes that are likely to be longer than their authors'.
For reference, just about every major shipping OS contains significant LoC dating back to the 70s or 80s.
Protesting the speaker's existence is difficult to intellectually justify as a healthy exchange of ideas, including critique.
These days, what we see is a lot of the latter -- up to and including attempting to prevent attendance of the event -- and very little of the former.
Sure it was. In the 1960s and 70s, for example, when Universities were a hotbed of free speech and civil liberty activism:
Hilarious. People called this issue out as an obvious flaw when HTTP/2.0 was first proposed, got ignored, and here the issue is.
For those unfamiliar:
HTTP/2.0 uses an unsigned 31-bit integer to identity individual streams over a connection.
Server-initiated streams must use even identifiers.
Client-initiated streams must use odd identifiers.
Identifiers are not reclaimed once a stream is closed. Once you've initiated (2^31)/2 streams, you've exhausted the identifier pool and there's nothing you can do other than close the connection.
For comparison, SSH channels use a 32-bit arbitrary channel identifier, specified by the initiating party, creating an identifier tuple of (peer, channel). Channel identifiers can be re-used after an existing channel with that identifier is closed.
As a result, SSH doesn't have this problem, or the need to divide the identifier space into even/odd (server/client) channel space.
Or just keep using protobuf2, 'cause it's been working great for us for ~6 years.
> But you don't have to do either. It seems like you aren't familiar with the use of protocol buffers.
I've written my own protobuf compiler. I'm familiar.
> You just define optional fields with a reasonable default, and magically all the old protobufs get that default value.
That only works up until there's no "reasonable default".
No, you didn't. A required field has a value, period. If it defaults to a particular value, then that's the value it has.
If you had a non-required field, then you marked it 'optional', and checked for the field's existence (or mapped optional fields to a Maybe/Option monad representation, forcing the issue).
Yeah. Don't do that without versioning your protocol. It's even less difficult to handle than maintaining API/ABI compatibility in a library.
> So practically speaking, you can never add required fields to any message where you can't guarantee binary version syncing amongst all instances of the message-dependent services.
Sure you can. If you version things at the protocol or per-request level, you can negotiate protocol conformance just fine.
Having a message type defined as "Message_V1" OR "Message_V2" is still simpler than having "any or none of the fields from any iteration of the message definition, where consistency is solely defined in terms of the field/message validation code you write in every protocol consumer".
> And if you're not running an RPC-based service architecture, then why are you using protos anyway?
It's a very serviceable compact serialization mechanism for at-rest data.
I feel the opposite; this greatly reduces the utility of protobuf.
Previously, I could trust that if parsing succeeded, then I had a guarantee of a populated data structure.
Now, I have to check each field individually, in manually written code, to verify that no required fields are missing.
That's really lame, and a huge step backwards.
What I see is the root of Communism; "No True Communist" is simple deflection.
1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities.
2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured.
3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing.
Of those:
1) Not much you can do, but issues are relatively rare.
2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry).
3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
In short:
We never standardized a viable schema that covered the majority of real-world enterprise use-cases. Active Directory did. We got stuck with the broken rfc2307 (essentially NIS-in-LDAP), and the slightly better but abandoned rfc2307bis.
Without a standardized schema, every management tool out there had to either expose LDAP directly, or provide a limited subset of operations supportable across random schema.
We could solve this issue with a new RFC defining a modern standard server schema, including things like sshPublicKey, but I don't know if there's any UNIX/Linux vendor still alive that would invest in doing so.
Using a 3rd-party cloud-based service to manage server authentication, SSH keys, et al, seems insanely insecure however -- especially when your alternative is simply running LDAP locally.
As a consumer, that would be a win.
As a developer, it would create a vibrant marketplace for media applications that simply can't exist today.
It's 2016, and these dead, flat, static PDFs are functionally identical to the paper they replaced!
There's a lot of value in static PDFs and how we format documents for publication. $CURRENT_YEAR doesn't invalidate good ideas from ($CURRENT_YEAR-n).
Just in terms of technology, static PDFs are:
- Easily distributed. - Easily archived. - Readable forever, even as platforms change incompatibly. - Readable on any device.
20 years from now, do you really want to have to run an old browser, or debug shoddy JS/HTML/whatever, just to read a paper from $CURRENT_YEAR-20?
Still prefer physical reference books.
Note that I'm not referring to API or library documentation; that's a different sort of thing.
I read all my fiction digitally, sure, but for technical/reference books, nothing has yet beat the UX of a paper book, and I'm unconvinced that anything in the near term future ever will.
I think you really have to treat books that are read sequentially vs consulted in random-access patterns as different beasts.
Twice.
https://www.freebsd.org/cgi/man.cgi?query=beadm&sektion=&man...
NeXt->Apple also avoided anything like systemd via a configuration system that supported inheritance across search domains (User, Local, Network, System):
https://developer.apple.com/library/mac/documentation/Cocoa/...