Why would anyone use split/join?
HN user
Bino
I actually think the old keyword is quite clever. I'm sure it could make sense in some places.
See https://www.freebsd.org/releases/11.2R/relnotes.html for release notes
It's really bad when you need a tl:dr on a security vulnerabilities release, it was a lot more bugs than I expected, I wonder if GitHub enterprises is just as bad?
If only there were a solution I could buy... ;) No, I do believe you should use Google Authenticator, it’s free, easy to implement and adds a lot of security over just passswords.
I feel they try to turn it into a feature... facepalm
I would say it all depends on why the do it, if there is a clear motive (like if they depend on it...then it makes sense for me and them and builds trustworthiness). But just sponsor something out of the blue - no. I don’t believe in random goodness when money is involved.
I say go for it, if you are not a key employee (there is no risk imho), you may just be a better fit in their other company.
Like it, as a runner and European citizen I always get confused if someone refers to American miles or not, but 5k is always 5000meters regardless? Do Americans who run ever talk about miles?
If you can, you should consider updating to 11.1 instead.
It's useful alright, however every time I'm reading records in a stream I prefer to have it prefixed with the record size in bytes.
However, having a new line delimiter is sure easier than trying to find the end of a JSON structure.
I would suggest you focus a lot on the design, research the history and design of other languages. Try to understand how they evolved and try to figure out their bad decisions on the way.
Eg.
Pythons PEP, PHP’s RFC, Mailinglists
Building the language itself is the easy part...
I once wrote an optimizing brainfuck compiler, it ended up running the bf code (if no input) and just printing the output in a single instruction :P
I think this case shows one of the pitfalls of compiled languages. If it can’t be optimized at compile time we’re out of luck so we aim too far.
I second that, it also allows moving and separation from different sites/publication systems (by DNS pointing). Also a valid concern: I seen main sites been redone/moved so many times while the docs stayed the same on its own subdomain...
So “meta projects” are now the most popular ones. It may reflect the non-developer mainstream who just found GitHub...
This one should really be up-voted to the frontpage.
It was unnecessary to split the protocol into two ports when STARTTLS came along shortly after. As for myself, I also thinks it's nice that you can partly identify the usage of a port by connecting to it.
I always favor STARTTLS in favor of implicit. I say so since implicit TLS on SMTP (465) is deprecated.
Out of curiosity: How could Blue Coat had prevent this? There must surely been a middleman? We should probably not argue they should have a kill-switch in their product?
So this release is actually all about HTTP/2 being ready for production! Congrats!
side note: why has the ANNOUNCEMENT MD5 checksums and not stronger hashing?
I found the discussion about the CVE more interesting than the bug itself.
I'm trying to understand if there is something more to it, because here is where I'm at, he found that some organizations has mistakenly or not configure their encryption gateways (MTAs) to accept mail from any host hence by connecting to them directly lets you bypass the anti-spam/virus filtering either directly to the mail server or by using the "trust" of the encryption gateway's IP?
He found some by spending time searching for them and gave the attach a name "the split Tunnel SMTP exploit".
Wouldn't it make sense to escape markdown syntax in the HTML? In HTML which you're converting from. * has not special meaning.
<p>foo</p>
I think we will come a far as we've done in memory safety with "logic safety", making programs that can't misbehave.
It's a very clever optimization (could it be categorized as vectorization?) in a very used part of the C library. In some cases these optimizations very justified.
In a strange way, I like their way of doing advertisement and driving business. While it's not true per-se, hitting the big targets (like Tizen, Linux kernel etc.) with bugs in a friendly way makes the smaller ones (companies) waiting to have the same powerful tool, the feeling of, if they have bugs, I might have a bug or two it could find...
Why dont improve on IMAP with extensions, I can't see how the "extending IMAP only makes it worse" argument hold. How would adding an addition protocol (JMAP) to a buggy client make the situation any better? I can see how it's easier for fastmail as a company to try to get its changes out by making another protocol, but would we not benefit better by trying to improve on IMAP? it's very unlikely this will ever replace IMAP and SMTPS from history internet always try to iterate and improve not replace standards completely? There is great effort to improve on SMTP and encryption lately, what can we learn from that?
All names in the .io zone are DNSSEC signed
hence, you should be able to do a DNSSEC walk?