To play devil’s advocate for a second - no-one is stealing anything, the code is still right where it was. If I willingly give someone a sandwich, did they steal it? Of course not.
There was a reason that PS chose FreeBSD, and it was because of the licence. If FreeBSD used the GPL then PS wouldn’t have used it, hence there never would have been a FreeBSD gaming OS either way.
Just us and these terrible men – for it is mostly men – who fell trees and spend other people’s lives as pocket change.
Tripped right at the finish line. What a great way to turn a clear call to action against the leaders in charge into meaningless gender-based infighting instead.
Strong disagree. I ran non-ECC memory on my server and services would unexpectedly crash maybe once per week. Over the span of a year I had two databases get corrupted that cost me a lot of time to fix. I tried swapping sticks but it happened with all of them. I switched to ECC memory and the problems disappeared. I needed more memory anyway and the price delta for ECC was about $100. I didn’t have to swap CPUs or anything, AMD desktop CPUs and chipsets support it out of the box. ECC memory is absolutely worth it.
Not that I know of, at least not for our cubesat. The aerospace sector moves extremely slowly because of ‘flight heritage’ - basically, if it hasn’t been in multiple long-term space missions before then it’s an instant rejection. You might ask ‘then how does any new tech get into space?’ and the answer to that is ‘it generally doesn’t’. More amateur satellite developers like university programs tend to ‘move fast and break things’ but with an emphasis on ‘break’.
Besides this suborbital flight I haven’t heard of anyone using carbon fibre frames before. I’m not a chemical engineer but I would imagine CF composites may have issues with outgassing, compared to metals. Outgassing can result in volatile compounds leaving suspension under a vacuum and depositing elsewhere, particularly bad for camera lenses and solar panels and such. Since the frame touches basically every part of the satellite, the risk here is high.
The original comment couldn’t understand why people were ‘raising their eyebrows’ at the price. I said because it’s basically a luxury item. Whether there are other alternatives that are even less value doesn’t factor into it. That’s the ‘door in the face’ fallacy.
Regardless of whether a Rolls Royce is more or less ‘value’ than a Lamborghini there’s gonna be a whole bunch of people that are gonna look at that and say ‘why would you spend X times the money when it gets you from A to B just the same as a Toyota Corolla’. That’s the answer to the original question.
Only when people comment that ‘the price is normal, actually’, and that I ought to buy one because they’re so cheap.
If it’s priced like a racing motorcycle then you shouldn’t be surprised when people raise their eyebrows at the price.
Sorry dude, I’m not paying $100 USD for a controller. The last controller I bought cost me ~$30 USD (GameSir T4 Kaleid) and has everything I need, including hall effect sticks. The steam controller having cool tech like touchpads and a gyro and whatever else is cool I guess, but I don’t need or want that. No amount of stuff like that is gonna make me spend that much on a controller.
So yes, the steam controller price raised my eyebrows, in the same way that basically all first-party controllers do. They’re all crazily overpriced imo.
This is not uncommon for high-profile CVEs. For example, brokenwire.fail, heartbleed.com, spectreattack.com, etc…
A solar flare is just one example of many possible causes. There are plenty of other ones. You didn’t touch on any of the others so let me explain - NASA reports on small satellite missions show that about 40% of satellites experience at least partial mission failure within their lifetime. Studies have shown the leading cause of satellite failure is propulsion systems, responsible for about half of all failures. This is not uncommon at all.
Most altitude ranges in LEO still have debris from decades ago, the exception being below 300km, which is basically still in the atmosphere. Unfortunately, debris strikes have regularly produced debris that are flung into higher orbits, so even collisions between satellites in this range are dangerous.
Edit: I also forgot to mention, the five day estimate (now three days actually) wasn’t for a close-call, it was for a debris-generating event.
Collisions aren’t theoretical, near misses are so common that there’s an entire department at NASA dedicated to detecting them and warning satellite owners to adjust course, I know because we were contacted about a possible collision involving our cubesat. Prior to megaconstellations being deployed if humanity stopped adjusting satellite orbits there would be a collision within a month, now there would be a collision within 5 days. It’s only a matter of time until both satellites on a collision course don’t have the ability to adjust course (engine failure or no propulsion/fuel/comms). In the event of a Carrington-style solar flare there’s a good chance a decent percentage of satellites would be knocked out, making this hypothetical into a reality. Further, we can only currently track objects down to about 10cm, but NASA estimates suggest about 500,000 objects exist between 1-10cm in size in LEO.
It seems to be even higher, several studies suggest it’s closer to 50%:
https://pubs.acs.org/doi/10.1021/acs.est.3c05002
Three different studies predicted emitted tire wear proportions (TWP and TRWP) of total emitted MP [microplastic] loads in the environment (both aquatic and terrestrial) for around 45%. (6,7,52) These calculations were mainly based on global, annual production data and matched the TWP proportions of around 40% in this study. However, since C-PVC was excluded here, a comparison of the percentages is not trivial.
If there’s moisture in the filament it vaporises in the extruder, causing steam bubbles that expand and disrupt the laying down of plastic, usually causing inconsistent extrusion lines (which itself causes poor layer adhesion). Some of the filament may end up being heated in the extruder slightly longer than other bits depending on these steam bubbles, which can cause overheating issues like stringing and oozing, etc…
Not to mention that filament that has absorbed water tends to become more brittle, which can lead to the filament snapping off before reaching the extruder. As a result, a filament’s shelf-life is usually dictated by how quickly it absorbs moisture (and also whether UV from the sun weakens it at all, but that’s a lot easier to manage).
What’s your ambient humidity? It’s usually around 80% here and I can barely get my dryboxes down to 30%
AES-256 is fine actually. The best known quantum attack reduces key strength from 256 bits to 254.4 bits. The problem is that in order to use AES (which is a symmetric encryption scheme) you need to exchange keys using an asymmetric system like RSA, which is known to be weak to quantum attacks.
Whenever you make a String you’re saying that you need a string that can grow or shrink, and all the extra code required to make that work. Because it can grow or shrink it can’t be stored on the (fast and efficient) stack, instead we need to ask the OS for some space on the heap, which is slow but usually has extra space around it so it can grow if needed. The OS gives back some heap space, which we can then use as a buffer to store the contents of the string.
If you just need to use the contents of a string you can accept a &str instead. A &str is really just a reference to an existing buffer (which can be either on the stack or in the heap), so if the buffer the user passes in is on the stack then we can avoid that whole ‘asking the OS for heap space’ part, and if it’s on the heap then we can use the existing buffer on the heap at no extra cost.
Compare this to taking a &String which is basically saying ‘this string must be on the heap in case it grows or shrinks, but because it’s an immutable reference I promise I won’t grow or shrink it’ which is a bit silly.
Here’s a little secret: All data types don’t actually exist. When your code is compiled down to machine code your computer just operates on collections of bits. Types are a tool we use to make code more understandable to humans. int and unsigned int tell us information about how numerical values are interpreted. bool tells you that only two values are going to be used and that the value will somehow relate to true/false. char tells us that the value is probably some sort of text. But again, everything is just stored as bits under the hood.
You can go even further and define new types, even though they might still just be numbers under the hood - you could for instance define a new type, e.g. Age, which is still just an integer, but it tells you the reader more information about what it is and what it might be used for. You might define a new type just for error codes, so at a glance you can see that this function doesn’t return an int, it returns an OsError, even if the errors are actually still just integer values.
C does however play somewhat loosely by these rules, and to try and ‘make your life easier’ will often ‘coerce’ types between eachother to make everything work. For instance, integer types can be coerced to booleans - 0 is false, everything else is true (even negative values). Later on you’ll find that arrays can ‘decay’ to pointers, and other fun surprises. Personally, I think this implicit coercion between types is one of C’s biggest mistakes. If types exist to help humans reason about code, what does it mean if the compiler needs to silently change types behind the scenes to make things work? It means the humans were sloppy and the compiler can only guess at what they actually wanted to do (and this is the best case scenario! What happens if the compiler coerces types in places humans didn’t expect? Bugs!).
There exist a spectrum of different behaviours in this regard, some languages are what we call ‘weakly typed’ (like Javascript, or to a lesser extent C) and other languages which are ‘strongly typed’. Weakly typed languages will try to implicitly convert types together to make things work: In Javascript if you try and add an integer to text "Hello!" + 52 the compiler will try to implicitly convert types until something makes sense, for instance in this case the compiler would say ‘oh, they probably want to add the text “52” onto the end’ and will produce "Hello!52". Sometimes this is handy, sometimes it introduces bugs. A strongly typed language will instead simply refuse to compile until you make the types line up.
C++ actually does this ‘optimisation’ for std::vector<bool>. I say ‘optimisation’ because it effectively trades time for space, which is usually the opposite of what you want - space is cheap, time usually isn’t.
Sometimes it’s a good tradeoff though - it’s common in embedded development where you might only have a few kB of RAM.
If you watched his videos you would know that the other chainmail grill scrubbers only appeared after he released his. The price difference is literally the central thesis of the video series - because the US has almost entirely outsourced manufacturing to countries like China and Vietnam, buying products from there are cheaper due to economies of scale. This gives those countries great economic leverage, and the US should not have been so happy to outsource. This can of course be reverted with sustained effort, that Destin is hoping to be a part of.