turminal

20 ms·

181.
by turminal 5y ago
> - iOS and Android: Power-efficient mobile systems, wakelocks, etc. - Docker, Borg and Kubernetes: Container isolation, cluster orchestrators. - Modern browser environments, with high degrees of isolation. - Fast JavaScript runtimes an
182.
by turminal 5y ago
> I'm pretty sure going to museums and restaurants and playing golf at off-peak times wouldn't be part of it. Why not?
183.
by turminal 5y ago
People always doing the easier thing is precisely why this industry is so broken.
184.
by turminal 5y ago
I remember first seeing it somewhere on cr.yp.to, where it was counted with some regex that did something like splitting it on some delimiter-like characters.
185.
by turminal 5y ago
It's not a lot of code but it's significantly less straightforward than the primitives tinyssh offers.
186.
by turminal 5y ago
Being tiny always means giving up some features. Supporting RSA really doesn't go along well with being tiny & straightforward.
187.
by turminal 5y ago
This looks like it's slowly improving though.
188.
by turminal 5y ago
I have looked quite closely into glibc in the past and there are great many things that could be improved and not using some of the fancy ELf features is probably one of them. For example symbol versioning doesn't appear to have a good
189.
by turminal 5y ago
> web3 means bug bounty programs are finally properly funded Can you provide some reference? Doesn't seem very feasible to me.
190.
by turminal 5y ago
These things just keep happening, don't they?
191.
by turminal 5y ago
> Your editor has DRM Lovely
192.
by turminal 5y ago
Why not just use some other editor?
193.
by turminal 5y ago
More scope creep? Browser are already way too big.
194.
by turminal 5y ago
Also, learn language x and understand the problem space it operates in before trying to kill it.
195.
by turminal 5y ago
Wow, this article is probably one of the best non-technical arguments against Rust I've ever read. Thankfully most of the Rust enthusiasts are not like this one at all.
196.
by turminal 5y ago
> it shouldn't be easy just as e.g. treating floating-point numbers as byte sequences shouldn't be easy. That's a nice analogy. > Doing find substring by find byte subsequence won't behave correctly in many cases,
197.
by turminal 5y ago
You are talking about what stringy things can be done with byte slices and I'm talking about all the byteslicy things that shouldn't be done with strings. Like subslicing. And accessing individual bytes in it.
198.
by turminal 5y ago
> Additionally, treating the string as an array of unicode codepoints I suggested no such thing. > individual codepoints inside grapheme clusters That's less severe than invalid codepoints. Perhaps the whole thing whichever way i
199.
by turminal 5y ago
> character slices Sorry, byte slices is what I had in mind. I'm not talking about language level string operations as in concatenation with + or something like that at all, because that certainly wouldn't make sense in languag
200.
by turminal 5y ago
By not treating strings specially, you get people screwing around with individual bytes inside codepoints which leads to at least as many bugs.
201.
by turminal 5y ago
> a codepoint is not a character Precisely. That's why I think representing strings as character slices and letting third party libraries handle them is not a good solution. Deciding what features to put in the language vs. the stdl
202.
by turminal 5y ago
The issue with treating strings as slices/arrays is that it exposes (writably!) the underlying representation, which is almost never what you want and leads to subtle bugs. The downside is of course the fact that you have to account fo
203.
by turminal 5y ago
They both have a single relevant implementation and for haskell in particular it's a complex behemoth. Haskell has a specification in theory but a sea of extensions exists. Ocaml does not have a specification. Ocaml lacks good docs and
204.
by turminal 5y ago
I don't think "$bigcorp uses $technology" necessarily means said technology is serious and reliable. It can also mean they just have a big enough dedicated team to adapt it well to their use case. Facebook uses btrfs in produ
205.
by turminal 5y ago
> Do you mean it makes it really hard for you or in general? I don't think I'm exactly alone, but there's definitely lots of people that would disagree. I know about Jane Street and I admire they manage to do so, but I als
206.
by turminal 5y ago
I like functional programming, but the way Haskell or Ocaml are built makes it really hard to consider them seriously for anything but research and/or fooling around.
207.
by turminal 5y ago
The only truly new thing in the last year is that it's in the news. The reality was always full of breaches and security holes. The paragraph you quote is mostly just inflating the issue in a typical journalistic manner.
208.
by turminal 5y ago
> "Shape" is too broad. Everyone has access to lots of almost identical tools from competitors. Exactly. That's precisely because Github is so big that nobody (except possibly sourcehut, but that's niche) dares to do
209.
by turminal 5y ago
Absolutely, but that doesn't make this kind of decisions at any particular host less bad.
210.
by turminal 5y ago
Care to elaborate why you believe so?

More ›