shockinglytrue

Given the frequency and consistency of narrative with which it appears in the press, at this stage I'm convinced it's an empty UAV used entirely for some marketing purpose

The press around the X-37B continues to perplex, it's particularly disappointing to see this "super secret but let's talk about it constantly" article using the word "very" 3 times.

I think it was drilled into me by the age of 12 to avoid "very" in written English in order not to obviously oversell, and yet here it is from a professional writer working for the BBC

IIRC it doesn't use ANS for every compression level, can't remember much more than that, though

It's been a few years, but I seem to remember there simply was no way to detect end of non-compressed content lacking a length header without first reading the TOC except substring search. This would quickly get very messy when the non-compressed content might contain another embedded ZIP, etc.

Well, we're not discussing creating zip files where seeking is an option, we're discussing streaming in the context of the attached link which uses it concretely in terms of writing to a network.

> Kind of a shame someone has to specifically implement a low memory usage library. That implies other implementations went the lazy route.

Streaming and seeking are antithetical, an implementation gets to pick one, and I imagine for most users streaming would be the edge case. It's debatable whether a library that ensures a fully spec-conforming output is generated at the expense of memory or IO is better or worse.

(FWIW this is written from the perspective of someone who for perverse reasons once wrote a streaming ZIP reader. In order to build such a thing, the ZIP writer had to be buffering/seeking. You can't have both without giving up ability to store uncompressed assets without needless overhead (e.g. JPEG-in-deflate))

Certain fields in the ZIP local file header require random access at write time. Although deflate is self-delimiting, for non-compressed items you must either know the size of item upfront, seek after learning the size, or force all readers to fully buffer the ZIP before decompressing any entry, in order to access the size stored in the central directory at the end of the ZIP

The CRC field of the local file header is similar, but its optionality is less painful than the length field

In other words, there isn't a single 'good' ZIP implementation, it all depends on what you're aiming for. AFAIK the built-in Python zipfile module always fully populates the local file header.

If performance doesn't matter, why bother attempt such a complex change at all?

There really was no hope of this without ditching reference counting, and consequently a much more destablizing change to the C API which was all but entirely unharmed during the 3.x transition.

There have been several attempts to bring new science to bear on solving the refcounting problem, I don't think any of them ever got far enough to be taken seriously

A significant chunk of Python performance is derived from optimizations made possible by the GIL - for example, so long as it is held, no additional locks are necessary to allocate a small object, unless that entails asking the system allocator for more memory

What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page.

There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.

Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.

I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.

"The page content is smaller as JSON" .. "you introduced a round-trip, game over"

"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"

"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"

I wouldn't presume to speak for everyone, but in my case particularly e.g. when making the leap back to PC away from macs, I poured over maybe 100 of this kind of review before settling on a final choice

If people weren't reading those articles the writers would not be incentivized to write them in the first place.

> tolerable cross platform toolkit

..for the 90s. There was very little about XUL that would survive today other than its layout model

Ignoring that XUL has a single implementation and for the most part a single application suite actually using it (not 100% true but very close), I'm not sure what there was to blow.

OTOH I remember some custom XUL apps of yesteryear, and they were always pretty nice to use. Does Firefox have any XUL left? I know there have been ideas to rip it out for a very long time.

I'm having trouble understanding what point is being made. Netflix entire business is shipping bulk data, I imagine the cost of transcoding and media management to be a rounding error in that grand scheme.

Netflix appears to support what I was saying rather than negate it

Try running any service with an average egress exceeding 10 Mbit/s then tell me cloud still makes sense. By the time you reach 1 Gbit/s the very idea of it is enough to elicit a primitive biological defensive response.

We don't do on-prem but we do make heavy use of colo. The thought of cloud growth and DC space consolidation some day pushing out traditional flat rate providers absolutely terrifies me.

At some point those cloud premiums will trickle down through the supply chain, and eventually it could become hard to find reasonably priced colo space because the big guys with huge cash-flush pockets are buying up any available space with a significant premium attached. I don't know if this is ever likely, but growth of cloud could conceivably put pressure on available physical colo space.

Similar deal with Internet peering. There may be a critical point after which cloud vendors, through their sheer size will be able to change how these agreements are structured for everyone.

This is why like me, you're not a cryptographer. AES256 is a cipher, its one component of a cryptosystem. Analysing cryptosystems is a complex area that does not involve vetting software for buzzwords.

I can take AES256 and make it output the image here: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...

That's not supposed to happen. The part where homebrew diverges from cryptography is that the former involves engineers like us connecting buzzwords together to produce images like the Wikipedia article, the latter involves complex math and rigorous peer review.

Serverless isn't a cure all, Ansible has had numerous code exec bugs due to e.g. interpreting strings coming back from remote machines or third party APIs as templates.

Some of these bugs aren't even that old

ansible-vault is homebrew crypto

Attributing this just to Salt is deeply unfair. Ansible has had many similar issues over time, also homebrew encryption etc.

CloudFlare's free plan can and does end at any moment, I wouldn't rely on it for any serious application

You're cute :)

Unfortunately the Firefox codebase itself is the only marketing tool at work here. I still use Firefox for everything else, not least due to the fact it isn't trying to swindle every last private detail out of me, but for work stuff and gaming (O365/GCloud) I don't really care about any of that.

Hiding behind lies and random personal attacks will not make Firefox better, but comparisons to its main competitor in key areas might help

I'm a diehard Firefox fan, but I will be honest: its JS and rendering performance is garbage compared to Chrome.

I play games and use complex web apps (GCloud, Office 365) exclusively in Chromium

Take a look at the Russell 2000 for a wider gauge of where money is flowing. Small businesses are still getting trashed

It claims to fix MongoDB

Much better link: https://github.com/hse-project/hse

PR is insane hot air referring to another hot air product (can you even buy their 3D Xpoint devices yet?)

Snaps (and Flatpak) are the app store pipe dream all over again, about 11.. 12? years too late. If anything treat them as early indicators of the future financials of these distros, if attempting this all over again is central to their future business model. Snap to me is synonymous with desperate.

While I don't like the tech, the real reason Snap pushes me away from Ubuntu is the fear of this future where the app store dream turned out to be a failure again. What happens to the distro then?

I think any xoogler will agree https://sites.google.com/site/testsitehacking/-36k-google-ap... is far more impressive.

It seems fairly safe to assume someone has already snapped this guy up. I can't recall the last time I felt so impressed reading some security writeup