This isn't "we are only going to sell products to big companies" nor is it "we are only going to make products that are locked down appliances"... the "consumer" versions of these products are just cheaper unreliable parts that lack the error correction or power loss protection of the enterprise parts, and in a world where we routinely have disks with tens of terabytes of storage in computers with a terabyte of memory, the argument for why "consumer" grade parts can even make sense to exist is pretty weak. It maybe sucks that, in the very short term, there will be a quick uptick in prices, but focusing on the better parts will also help bring their prices down... and, fwiw, they really aren't that bad to begin with: you can build a micro-ATX machine with a Xeon or an EPYC in it for what feels like a pretty reasonable price.
Yeah... I was super excited by this project when it was first announced--and would even use it from Wasm--but since it ONLY works in Wasm, that seemed way too niche.
But that isn't the same code that you were running before. And like, let's not forget GPLv3: "please give me the code for a mobile OS that could run on an iPhone" does not in any way help me modify the code running on MY iPhone.
Sure it does. Just tell the model to change whatever you want changed. You won't need access to the high-level code, any more than you need access to the CPU's microcode now.
We're a few years away from that, but it will happen unless someone powerful blocks it.
I believe the point was that iPhones don't even allow running custom code even if you have the code; whereas GPLv3 mandates that any conveyed form of a work must be replacable by the user. So unless LLMs easily spit out an infinite stream of 0days to exploit to circumvent that, they won't help here.
So like, in the United States, if you book directly via Marriott, the number of beds isn't guaranteed unless you have some reasonable status at the hotel.
If you book a queen room isn't it always 2 beds? A king room is usually 1 bed. Is there some option where it's just totally random what room you get? I don't have any Marriott status but going on their site I can clearly see a choice of rooms, and each one says what amenities it has.
The point is that you aren't guaranteed the room type you select: you'll show up at the Marriott and they'll give you a room with one king instead of the room with two queens you thought you booked; your selection is just a preference, not a lock.
^ you have to have Platinum status to get the type "guaranteed"... and, even then, they might just give you $25-100 and say "sorry" (it is more of an SLA with a penalty; though, this is also true of the reservation itself... FWIW, getting a random room type is MUCH more common than getting bumped).
Too true. If you have a normal reservation (vs some kind of pre-paid room), they oversell their capacity based on a statistical model. This means if everyone with a reservation shows up, some of the last to check in won't have a room (which tends to occur during statistically unusual events like a large trade show, where every reservation is more likely to show up). The hotel will basically just say "sorry" and suggest another hotel which may have rooms. I think they try to recommend hotels that are nearby and similar but sometimes that either doesn't exist or is also sold-out.
One of the benefits of having platinum status at Marriott is they'll actually guarantee your room but platinum status isn't easy to get. I used to frequently drive into the bay area late at night to avoid traffic, arriving at the hotel at midnight or later. Being platinum at the time, I'd sometimes get a call on my mobile from the manager after 9p to find out if I was showing up for sure and I'd tell them "Yep, I'm driving now." That's how I knew they were sold out and bouncing people with reservations. They didn't want to keep holding my room if I wasn't going to show up (being platinum there was no penalty for no-showing on a reservation).
A tip: if you have a non-guaranteed reservation and you think the hotel is likely to be full but you're arriving later in the evening - call the actual hotel front desk before 5p (not the reservation center), ask to speak to the manager on duty and ask them to check you into your room over the phone. Ask for the actual room # and then have them actually print out your card key and put it in an envelope under your name at the front desk. Once your reservation has been checked in, a room assigned and a key printed, it can't be given away by the late shift.
> Why would someone think they would keep the weight off? If they could they would have before Ozempic.
I think the intuition many people have--which I am not at all defending as correct, but it certainly isn't so obviously wrong that we should scoff at someone for thinking it works this way--is more like "if my weight was stable before I did this intervention, I just need to lose the weight and then my weight will once again be stable after it"; in this mental model, one would assume you only need lots of willpower to lose weight: after, you only will need as much willpower as you already know you have to not gain it back, as it isn't as if you are gaining weight currently.
> I'm also not a fan of buy bigger storage concept, or the conspiracy-theory on 480 v 512.
I don't understand why this is being called a "conspiracy theory"; but, if you want some very concrete evidence that this is how they work, a paper was recently published that analyzed the behavior and endurance of various SSDs, and the data would be very difficult to describe using any other theory than that, comparing apples-to-apples on drives that have better write endurance, they are merely overprovisioned to allow the wear-level algorithm to not cause as much write amplification while reorganizing.
> OP on write-intensive SSD. SSD vendors often offer two versions of SSDs with similar hardware specifications, where the lower-capacity model is typically marketed as “write-optimized” or “mixed-use”. One might expect that such write-optimized SSDs would demonstrate improved WAF characteristics due to specialized internal designs. To investigate this, we compared two Micron SSD models: the Micron 7450 PRO, designed for “read-intensive” workloads with a capacity of 960 GB, and the Micron 7450 MAX, intended for “mixed-use” workloads with a capacity of 800 GB. Both SSDs were tested under identical workloads and dataset sizes, as shown in Figure 7b. The WAF results for both models were identical and closely matched the results from the simulator. This suggests that these Micron SSDs, despite being marketed for different workloads, are essentially identical in performance, with the only difference being a larger OP on the “mixed-use” model. For these SSD models, there appear to be no other hardware or algorithmic improvements. As a result, users can achieve similar performance by manually reserving free space on the “read-intensive” SSD, offering a practical alternative to purchasing the “mixed-use” model.
> My ideal environment would be Windows 95-like WM with zero configuration options which just works out of the box the way I want.
Why would we have any reason to believe that there would ever be a super-opinionated desktop environment that would be good? The examples we have -- which notably DO NOT include Windows 95, which had a zillion tiny knobs, many in the UI, but others requiring dropping to the registry (which is no different from screwing with confirmation files)... and, frankly, doesn't even include macOS, the system with some of the best customization of key bindings and the most universal automation -- are mostly bad. Put in the day or two of effort to make something that isn't opinionated work the way you want, and then reap the rewards for the following few decades of your productive career.
I really really wish the ecosystem had simply gone with "trunk" (which is also what Subversion had used, in addition to actually matching the metaphor in play; though, I get that some people don't consider trunk to be a branch... but it is already used in this context for "trunk-based development").
Outside of the context of the culture war, it has gotten a project or two that I've seen to really think about what they should name their branches, and how they could better describe what kind of development happens in them.
Branch names like "stable", "next", and "protobreak" are a lot more understandable than "master" or even "main."
Only if you already upgraded to the one with the bug in it, and then only if you ignore "this patch is actually different: read this notice and deploy it immediately". The argument is not "never update quickly": it is don't routinely deploy updates constantly that are not known to be high priority fixes.
But that isn't what you said? ;P "f you wait seven days, you're pointlessly vulnerable." <- this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch... but, if some new configuration file feature is added, or it is ported to a new architecture you aren't using--aka, the 99.99% of patches--you don't deploy THOSE patches for a while (and I'd argue seven days is way way too small) until you get a feel that it isn't a supply chain attack (or what will become a zero day). Every now and then, someone tries to fix a serious bug... most of the time, you are just rolling the die on adding a new bug that someone can quickly find and exploit you using.
> this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch...
The policy being proposed is that upgrades are delayed. So in a company where that policy was enforced, I would be required to request an exception to the policy for your hypothetical patch.
That's unacceptable for me. That's requiring me to do extra work for a nebulous poorly quantified security "benefit". It's a waste of my time and energy.
I'm saying the whole policy is unjustified and should never be applied by default. At all. It's stupid. Its harmful for zero demonstrable benefit.
I'm being blunt because you seem determined to somehow misconstrue what I'm saying as a nitpicky argument. I'm saying the whole policy is terrible and stupid. If it were forced on me by an employer, I would quit. Seriously.
If your internal process is willing to ship and deploy upgrades--whether to your code or that of a third party--without testing even so minimally to notice that they cause almost a 100% chance of crashing, you need the advice to slow down your updates more than anyone...
Obviously, they caught the bug and didn't deploy it.
The point is that a change to a completely unrelated component caused a latent bug to make the device unusable, ended up delaying a release for weeks and causing them have to pay me a bunch of money to fix it for them.
If they'd been applying upgrades, they would have never even known it existed, and all that trouble would have been avoided.
I mean, I'm sort of working against my own interest here: arguably I should want people to delay upgrades so I can get paid to backport things for them :)
reply