[permalink]2019 ...
januari (3) februari (1) maart (3) april (3) mei (3) juni (1) juli (2) augustus (1) september (1) oktober (2) november (1) december
Open source is nice, but is the protocol also open (enough)?
2019-01-15 08:57
openproto
[permalink]
See, this is something I'm very very worried about: things like Bitcoin — big public successful open-source projects — have the appearance of being complete open and public, but the protocol isn't really.
When I was first looking into Bitcoin and learning what it is about, really, I'm quite sure this can only have originated out of a tightly connected bunch of people that were very serious about 'disconnecting' from anything vaguely institutional. Any structure set up by people to govern any kind of transactions between them, has the tendency to limit liberties of people, for the people taking part in the system and sometimes also for those that don't. So it's only natural that Bitcoin at its code is a peer-to-peer protocol.
But. How do people that value anonymity and independence from any system, even get to find each-other and communicate to build things together? Well, the internet of course. But perhaps more importantly — and also since long before the internet — cryptography. Encoding messages so that only the one with the (correct) key can decode and read the message, helps to reduce the cloak-and-dagger stuff to exchanging these keys, and enables to send messages in the open. To the uninitiated onlooker it looks like a meaningless block of code, and in a sense it's exactly that. Unless you what to do with it, and have the key — or would like to have it.
Another use of encoded messages is proving it's really you that originally encoded a message. It's what's behind the Merkle tree that the blockchain runs on. That way the entire trail of transactions is out there in the open, all signed with safely stored private keys. The reader can verify with the public keys, and in fact these verifications buzz around the network and are used to supervise the current state of the blockchain, building a consensus. Sometimes two groups disagree and the chain forks, but that's another story.
The protocol, or the agreement of how to put this into bits and bytes in network packets, can get quite complex. It needs to be really tight and dependable from the get-go, see the article I linked to above. You could write it all down and still have nothing that works, so what typically happens is you create a program that does it and test it to see how it behaves. In this case it's a peer-to-peer networking program so you distribute it among your peers.
But when things get serious, you really need the protocol written out at some point. If you try that and can't figure out any more what really happens, you're in trouble. The protocol could help other people to create programs that do the same, if they would want to. This was something the early internet was all about: people got together to talk about "How are we going to do things?" and then several people went out and did it. And could interoperate just fine. (Or worked out their differences. In the best case.) It typically resulted in clean and clear protocols with the essence up front and a clear path to some additional things.
The existence of the open-source software culture it another story altogether, but I'm very worried it is starting to erode the requirement for clean protocols more and more. If people think "if we can't find out how the protocol exactly works, we can just copy the source of the original client/server" nobody will take the time to guard how the protocol behaves in corner cases and inadvertently backdoors will get left open, ready for use by people with bad intent.
2019-01-18 08:53
jsondoc12
[permalink]
I don't really know where my open-source/freeware projects get used by other people (and I don't really care all that much, really), but ofcouse where I use my private libraries in the projects of my day job, I've got a first-row seat to see how they perform. No, even better, I'm the stagehand. I know it's important to keep the two separated though. At work I can only use and call libraries, never work on them. I can make changes, but I would have to do so like anybody else: clone a local repository, store the changes there, and when they're ready have the good manners of sending out a pull request. If 'at-home’-‘hobbyist-programmer’-me decides to merge it, it makes my employer a co-creator of the project, creating a new legal situation that my employer would need to know about.
What I can also do, ofcourse, is let private-me know that ‘at-work’-me would really like this or that extra feature or interface, and then when I can put some evening time into programming, I can see if I get round to it. Github issues are nice for that. Or Post-It's on my car key...
But recently I've got a real decent suggestion from a collegue. It didn't come in over a pull request, but it made sense, so why not put it in at the base:
https://github.com/stijnsanders/jsonDoc/commit/fb01e0865fa888c7441234726dc4a90b0c802582
The IJSONDocument interface has Parse to load data from a string holding JSON data, and a function ToString to convert the contents back to a string. For jsonDoc (and bsonDoc before that) I want concise syntax, so I though I'd make Parse a function that returns Self so you can chain calls. But my collegue wondered why IJSONDocument doesn't have a property AsString:WideString;. In theory it would have read ToString write Parse, except Parse needs to be a procedure, not a function. So I had a close look and changed it around. Another option would be to add an extra procedure SetString, but that would mean the virtual method pointer table for the IJSONDocument interface would have an extra item, to a method with exactly the same behaviour, which makes little sense.
So I changed it around. If you really like/need chaining, there's still the function JSON overload that takes a Variant. If you pass it a string, it'll call plain function JSON to get a new instance, and call Parse for you on the string.
Tweedehands diesels raken niet verkocht
2019-01-26 12:27
diesel
[permalink]
→ Standaard: Tweedehands dieselwagens raken niet verkocht
Eerst dacht ik “in plaats van te demonstreren, zouden ze niet beter massaal hun diesels verkopen en voor dat geld nieuwe zuinige benzinewagens kopen? En voor die die echt veel kilometers doen op gas.” Maar als het al zo ver is dat er geen vraag is om dat extra aanbod te slikken (zelfs in het buitenland), dan geeft dat opnieuw reden om in opstand te komen. Maar wat moet je dan doen als staat? Is het eigenlijk mogelijk om dieselmotoren om te zetten zodat ze op iets draaien van mindere smeerlapperij? Waarschijnlijk niet met minder uitstoot en lagere prijzen aan de pomp...
Zelf al was het mogelijk een je geeft voluit premies, krijg je gegarandeerd een scheefgetrokken situatie die daarna dan weer tientallen jaren meesleept. (Zonnepanelen, iemand?) Dus komen weer bedrijfswagens in beeld. Misschien nog zo'n slecht idee niet eigenlijk. Als ik het juist begrepen heb hangt er heel veel af van de geschatte waarde bij verkoop na 4 jaar, en van die nieuwe auto's is dat nog helemaal niet zeker.
Zou dat geen mooie rol te spelen zijn door vadertje staat? Gewoon voor vier jaar garant staan dat door auto's nog goed verkocht gaan raken na hun contractduur? Op zich kost het niets een de kans is groot dat ze uiteindelijk vlot toch een nieuwe eigenaar vinden aan een eerlijke prijs. Maar in ons Belgenlandje zit je dan over het einde en begin van legislaturen. Aj. Tja, noppes dan zeker? Soit, ik ben benieuwd wat ze wel gaan uitvinden. Misschien kunnen we er nog eens goed om lachen.