__roland__

Sure, that's true. The thing is: this was the same requested (and cancelled) range on the same file(s), over and over (it was a bug). Looking at this from the outside, even some internal S3 caching should have had many cache hits and not have to re-download the requested ranges internally all the time (there were dozens of identical requests per second, immediately being cancelled).

On top of this, S3 already bills (separately) for any request against a bucket (see the other current issue with the invalid PUT requests against a secured bucket, which still got billed to the bucket owner; https://news.ycombinator.com/item?id=40203126). So I'd say both the requests and the cancellations were already paid for; the surprise was the 'egress' cost on top, of data that was not actually leaving the AWS network.

Still, you are right that this still consumes some additional AWS resources, and it is probably a non-trivial issue to fix in the 'billing system'.

Sorry for not having this made clearer (we'll fix this part of the post): the gotcha is not that AWS does not honor range requests, it's that canceling those will still add the full range of bytes to your egress bill (and this can add up quickly) although no bytes (or much fewer) have been transferred.

I can assure you this was not AI-generated, apart from the 'symbolic image' (which should be fairly obvious :).

Maybe that's just our non-native English shining through. In any case, as a small European company in the healthcare space, we are quite used to having to explain "the cloud" (with all potential and pitfalls) to our customers. They are also (part of) the target audience for this post, hence the additional explanations.

(Not OP and not author of the article, but was involved in the write-up.)

You are right, this is about canceling range requests and still getting billed, not about requesting ranges and getting billed for the complete file egress. Sorry; we'll make the post clearer.

Sorry, I think that part of our write-up is misleading (I was involved in analyzing the issue described here). To our best understanding, what happens is the following:

- A client sends range requests and cancels them quickly.

- The full range request data will be billed (NOT the whole file), so I think this should read that the entire requested range gets billed, even if it never gets transferred (the explanation we received for this is that it's due to some internal buffering S3 is doing, and they do count this as egress).

In any case, if you send and cancel such requests quickly (which is easy enough, this was not even an adversarial situation, just a bug in some client API code) the egress cost is many times higher than your theoretical bandwidth (and about 80x higher than in the AWS documentation, hence the blogpost).

You are right: the horizontal scroll only appears if you scroll down to the bottom of the page. But there is also a (more sensibly layouted) program shown on each streaming page (e.g. https://streaming.media.ccc.de/rc3/two, "Fahrplan" tab)

Totally agree. I think his paper "Can a Systems Biologist Fix a Tamagotchi?" is really nice, shows some of the fundamental conceptional issues and very fun reading nonetheless: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.131...

Just as an anecdotal counterpoint to all the negative reviews here: I have a 2015 Tuxedo notebook that is still going strong, and never had any issue with it. There is quite a bit of fan noise, which I don't hear as I'm typically using a noise-cancelling headset anyway. The keyboard is rather flimsy and the build quality is definitely not on par with Dell XPS or a T-series Lenovo, at least for this model: in my use case (using external keyboard and monitor 99% of the time) this is not an issue, so I'm (still) quite happy with it. As others have already said, the pricing is hard to beat and its Ubuntu setups are well configured.

I also had very positive interactions with their support staff; very friendly and knowledgeable. I have yet to see a piece of Tuxedo hardware fail, and know several people who are using their hardware (both laptops and workstations, which are even nicer and have a much better build quality IMO).

Ah cool, I didn't know about that. Thanks!

Instead of writing blog posts as a vital sign, maybe it would help to offer some regularly updated pre-defined "bundles" of ST together with package sets for a certain audience (JS/TS/Python developer, etc.). Many packages have a higher update frequency, so even when there is no new ST build it would make sense to also update such bundles on a more regular basis (I know packages are updated automatically -- but this would give a better impression regarding the activity and the size of the ST community for new users).

I imagine the introduction of something like "Sublime Text distros" in package control, which would provide ST users something akin to the different Eclipse flavors (or the various .vimrc settings available online) could be quite useful. While the package control setup is already pretty straightforward, it is still rather confusing for new users that they have to manually install such a 'basic' feature (and Atom, for example, is much more polished in that regard).

It's strange that their website is so bad (lots and lots of ads, basically unusable without an ad-blocker) while their apps (in particular, Espresso) are a joy to use.

I think one way to 'treat' this would be to acknowledge that certain things just cannot be optimized easily with outside incentives, and to simply accept that there will be some inevitable waste when you let 'good people do their job as best as they can'.

It's ironic that we fret so much about professors that 'retire on the job', but at the same time think it is perfectly fine to steal time from the motivated researchers, by making them playing these silly games too.

Who really thinks the next breakthrough will come from a person that was forced into writing another paper, just to pass some arbitrary performance threshold?

If you consider research as a 'stochastic race', i.e. many people working on a problem with their own intuitions and approaches, it makes no sense to slow down those that are most likely to come up with a good solution (those that are self-motivated). IMHO, it does not really matter if those that are unlikely to contribute much (retired on the job) get a free pass. After all, even to receive tenure takes a lot of effort (and thus, ambition) nowadays, so at least in fields with a competitive job market (i.e. good salaries outside academia) it makes no sense to strive for a tenured position and then not do what you love (i.e., research).

BTW Daniel Lemire's blog has many interesting posts on the more absurd aspects of academia, including research grants (e.g. http://lemire.me/blog/2009/09/15/the-hard-truth-about-resear...). IIRC one of his suggestions was so fund people (for longer terms), not 'projects'. This may not always be possible (e.g., if you need expensive equipment), but in many fields it would make much more sense.

EDIT: language

Redshift still works quite well. Maybe it should be pre-installed and better 'advertised'. Many people still don't know that this is a very nice feature to have.

- FLAVOR: Desktop

- HEADLINE: improve VPN support

- DESCRIPTION: the WLAN UI supports some OpenVPN options, but not all, and fails silently on importing non-compatible config files. This is very confusing for new Desktop users.

- FLAVOR: Desktop

- HEADLINE: multi-column list view in nautilus

- DESCRIPTION: This view has been explicitly dropped (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/7081...) but is very useful for quickly navigating large directories. Alternatively, replace Nautilus with a file manager that can do this (like Nemo). This is one area where the Windows file manager is still much better.

- FLAVOR: Desktop

- HEADLINE: polish file dialogs (multi-column-list view)

- DESCRIPTION: the default file-open and file-save dialogs lack many simple features that can save a lot of time. For example, in the file-open dialog there is no multi-column view (see above), you cannot rename files, you cannot create files/folders, you cannot access the normal context menu. All this requires separately opening a file manager, which also lacks a few productivity features (see above).

- FLAVOR: Desktop

- HEADLINE: polish hotkeys and general window handling on multi-monitor setups

- DESCRIPTION: I needed a bunch of compiz plugins to make this work in a halfway decent way in a 2-monitor setup, and I dread the day I will have to re-shuffle this for a 3-monitor setup etc. Make it easy to move a window 1) from one monitor to the other, 2) resize and move to one of the corners/sides, 3) maximize it. Also, applications in full-screen mode on one of the monitors confuse my compiz-based setup (for example, a full-screen Chrome window on one monitor will introduce numerous UI issues).

Still, it's a great system and very nice to use overall.

Thanks for gathering feedback. That's the first step ;-) Keep up the good work!

Edit: language

I noticed an improvement over the last version, so I'd give it a spin.