It's funny, David Brin used to flog the idea of "sousveillance," meaning that mass surveillance was inevitable and couldn't be reformed but we could use it to hold the elite accountable. What a joke.
I'm relatively certain that neither Concorde nor any passenger jets burn aviation gas. It may be physically possible, but would be extremely ill advised given the lead additive
I'm pretty sure they weren't referring to 100LL, but either way even back in the 90s Jet-A was around USD 0.50 per gallon, in the 60s it was nearly 1/5th of even that.
Fair. Edited my comment to note that both sorts of fuels were in that price range, but didn't look up the specific fuel specification used by the Concorde.
Some version of Aviation Turbine Fuel (the other ATF) is used in passenger jets, which is either Jet A or Jet A-1 for colder, non-American flights. It is a kerosene-based fuel which does not contain any lead.
In the states I've lived installing a big screen like that in your car is against the law. Unless the manufacturer specified it as original equipment. So yes, a bigger screen is a selling point
Somewhat ironically if they were laser focused using infared lasers, wouldn't that imply the company was not very specific at all? Infared is something like 700 nm, which would be huge in terms of transistors
State of the art lithography currently uses extreme ultraviolet, which is 13.5nm. So maybe they are EUV laser-focused, just with many mirrors pointing it in 5 different directions?
It'd be interesting to see some market survey data showing the number of AI laptops sold & the number of users that actively use the acceleration capabilities for any task, even once.
Remove background from an image. Summarize some text. OCR to select text or click links in a screenshot. Relighting and centering you in your webcam. Semantic search for images and files.
A lot of that is in the first party Mac and Windows apps.
I don't find gas leaf blowers exceptionally annoying. They aren't really anymore annoying that anything else going on in my area. It's what leaf blowers are used for that bother me. I see people just using them to blow leaves either into the street or into neighbors yards. What is the utility in this? Do they think leaves disappear?
They’re much louder than other common lawn equipment. People also tend to use them more frequently. Most of my neighbors will only run a lawnmower once a week or every 2 weeks. But they’ll be out there every day with a leaf blower during parts of the year.
Agreed, but I'm comparing them to the other stuff that is always going on. During the week you can always hear: roofing nailguns, wood chipper, backup beeper, & someone playing music.
That depends on where you’re at. I live in a neighborhood with 2-5 acre lots. I can’t hear any of those things unless my immediate neighbors are doing them, which they rarely are.
I can hear leaf blowers constantly though because you can hear them in a quarter mile radius.
Also local ordinances in most places ban loud noises without a permit. But lawn maintenance equipment is a specific exception.
I've owned the property I've been referring to for over 6 years. Never seen a street sweeper. Leaves in the street from my neighbors yards are about 1 foot deep at the curb
Likely yes, because NASA and other agencies were able to portray the incident as an O-ring failure. It was in fact just that management was indifferent to the risk to the astronauts on board. The only individual who accurately reported on the disaster was Feynman.
I normally disagree with such broad remarks, but in the case of C++ I agree. I sometimes see a less common feature of Python used and have to remind myself of the syntax and its usage. With C++, I start any project with the idea that I will only use a small subset of the available features. When I review other's code I pretty much need a language reference available at all times until I can settle into their particular flavor of C++
malloc() and friends may always return NULL. From the man page:
If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM.
In practice, I find a lot of code that does not check for NULL, which is rather distressing.
No non-embedded libc will actually return NULL. Very, very little practical C code actually relies only on specified behavior of the spec and will work with literally any compliant C compiler on any architecture, so I don’t find this particularly concerning.
Usefully handling allocation errors is very hard to do well, since it infects literally every error handling path in your codebase. Any error handling that calls a function that might return an indirect allocation error needs to not allocate itself. Even if you have a codepath that speculatively allocates and can fallback, the process is likely so close to ruin that some other function that allocates will fail soon.
It’s almost universally more effective (not to mention easier) to keep track of your large/variable allocations proactively, and then maintain a buffer for little “normal” allocations that should have an approximate constant bound.
This is just a Linux ecosystem thing. Other full size operating systems do memory accounting differently, and are able to correctly communicate when more memory is not available.
There are functions on many C allocators that are explicitly for non-trivial allocation scenarios, but what major operating system malloc implementation returns NULL? MSVC’s docs reserve the right to return NULL, but the actual code is not capable of doing so (because it would be a security nightmare).
I hack on various C projects on a linux/musl box, and I'm pretty sure I've seen musl's malloc() return 0, although possibly the only cases where I've triggered that fall into the 'unreasonably huge' category, where a typo made my enormous request fail some sanity check before even trying to allocate.
> There are functions on many C allocators that are explicitly for non-trivial allocation scenarios, but what major operating system malloc implementation returns NULL?
Solaris (and FreeBSD?) have overcommitting disabled by default.
Solaris, AIX, *BSD and others do not offer overcommit, which is a Linux construct, and they all require enough swap space to be available. Installation manuals provide explicit guidelines on the swap partition sizing, with the rule of thumb being «at least double the RAM size», but almost always more in practice.
That is the conservative design used by several traditional UNIX systems for anonymous memory and MAP_PRIVATE mappings: the kernel accounts for, and may reserve, enough swap to back the potential private pages up front. Tools and docs in the Solaris and BSD family talk explicitly in those terms. An easy way to test it out in a BSD would be disabling the swap partition and trying to launch a large process – it will get killed at startup, and it is not possible to modify this behaviour.
Linux’s default policy is the opposite end of that spectrum: optimistic memory allocation, where allocations and private mappings can succeed without guaranteeing backing store (i.e. swap), with failure deferred to fault time and handled by the OOM killer – that is what Linux calls overcommit.
It's been a while but while I agree the man page says that, my limited understanding was the typical libc on linux won't really return NULL under any sane scenario. Even when the memory can't be backed
I think you're right, but "typical" is the key word. Embedded systems, systems where overcommit is disabled, bumping into low ulimit -v settings, etc can all trigger an immediate failure with malloc(). Those are edge cases, to be sure, but some of them could be applied to a typical Linux system and me, as a coder, won't be aware of it.
As an aside: To me, checking malloc() for NULL is easier than checking a pointer returned by malloc on first use. That's what you're supposed to do in the presence of overcommit.
Even with overcommit enabled, malloc may fail if there is no contiguous address space available. Not a problem in 64 bits but may occasionally happen in 32 bits
But why would you want to violate the docs on something as fundamental as malloc? Why risk relying on implementation specific quirks in the first place?
https://en.wikipedia.org/wiki/Sam_Francis_(writer)
reply