I don't see this happening any time in the near future. The extra hardware cost is nontrivial, and there's a software support burden. Cellular bandwidth also isn't free, and probably wouldn't be covered by the value of any ads/telemetry that it carried.
> Somebody will be left holding the bag eventually.
I think so too. I also thought that about Facebook: IPO around 40, swiftly down to 20 - I was laughing about stupid retail getting wrecked. Now it's around 600...
Maybe you are right, maybe not.. However Facebook as an example seems entirely irrelevant, though? It was valued 15 P/S ratio at IPO and went down to 10 a year after the IPO. You'd have a point if Facebook IPO at $400 instead of $40. But it took it 10 years to reach that.
SpaceX IPO price already has many years of extremely high growth priced in. Comparing it to Facebook's or Google's IPOs is like apples to oranges.
> Children are expensive, but highly subsidized, and just not expensive enough to explain the whole picture.
Highly subsidized? I have to assume you're not talking about America. I pay $3200/mo to send my kids to a very middle-of-the-road preschool. That's almost $40k/year just in childcare costs so that my wife and I can go to work. The difference between a 1-bedroom apartment and a 3-bedroom apartment is an extra $20k/yr or so in my area. Then there's health care premiums, taking them out for activities sometimes, etc.
I can ballpark the cost of having preschoolers in my area as $30k/yr each. And I don't know about you, but I don't exactly see any government subsidies helping me carry that burden.
Get poorer, or get in a better location. Preschool is covered free here, with a pittance for after-school care (which is covered if your income is below something like 3x the poverty line).
Having kids is wildly subsidized for the poor - plot all the bennies available to a family at 2x the poverty line.
Jesus Christ! I don't have children, but if that is what it would cost, then I would definitely never have a child. It would feel like sacrificing my entire life, just to produce another generation. No, then I'd much rather just enjoy life, and melancholically look at the families who have to struggle every day to make ends meet due to their children. It is really quite sad. But I guess nature in its wisdom, transforms a person who has a child, so that that child becomes the only meaning in life for that person. If not, there simply would be no children and we would not be able to write this.
Something I'd observe here: without expressing an opinion about PEGs vs regexes, I'd note that regexes are much more widely used. They're also completely sufficient for an awful lot of text processing tasks. PCRE regexes would be a great inclusion to the stdlib, and would probably be popular.
PEGs are a great replacement for a complicated regex, and can express a lot of things that are hard to do with a regex. But they're also more verbose, and fewer developers are familiar with their usage. PCRE regex is kind of the lingua franca of text-matching, and making it available would be helpful for newcomers imo.
Tcl is pretty good at functional-programming type stuff, and it can absolutely do anything that you could do with a macro. It isn't Algol-like at all imo, maybe beyond some superficial syntax. It feels a lot more like if LISP and Bash had a baby out of wedlock.
(I've written a lot of Tcl over the years and it'll always have a spot in my heart)
We use a Docker Compose setup for our team's devcontainer. It's defined right in the repo alongside the Dockerfile used to build our image. Our build scripts are all set up to start/stop/use the container automatically. Integration with Vscode's devcontainer system will come next.
It's been a great way for us to make sure that developers and CI/CD get exactly the same build environment, mount-points, paths, network access, permissions, etc.
It's been a super solid tool overall, and I'm pretty happy with it. The only thing that would make our setup better would be if we could figure out how to go rootless/daemonless with it.
You only have to decompress it first if it's compressed (commonly using gzip, which is shown with the .gz suffix).
Otherwise, you can randomly access any file in a .tar as long as:
- the file is seekable/range-addressible
- you scan through it and build the file index first, either at runtime or in advance.
Uncompressed .tar is a reasonable choice for this application because the tools to read/write tar files are very standard, the file format is simple and well-documented, and it incurs no computational overhead.
You've just constructed your own crappy in-memory zip file, here. If you have to build your own custom index, you're no longer using the standard tools. If you find yourself building indices of tar files, and you control the creation, give yourself a break and use a zip file instead. It has the index built in. Compression is not required when packing files into a zip, if you don't want it.
Yeah it's pretty common to use zip files as purely a container format, with no compression enabled. You can even construct them in such a way it's possible to memory map the contents directly out of the zip file, or read them over network via a small number of range requsts.
You can achieve the same with tar if you individually compress the files before adding them to the tar ball instead of compressing the tar ball itself.
I don’t see how that plus a small index of offsets would be notably more or less work to do from using a zip file.
Zip has a central directory you could just query, instead of having to construct one in-memory by scanning the entire archive. That's significantly less work.
I mean if they include a pre-made index with it. For example an uncompressed index at byte offset 0 in the tar ball that lists what is inside and their offsets. It would still be comparable amount of work to create software to do that with tar as to use a zip file, if fine grained compression levels etc is being used.
I suppose you are right about that. But it would still be a valid tar file that can be viewed and extracted with normal tools. Kind of similar to how a .docx file can be extracted as zip but still has additional structure to its contents.
What are you really proposing? That a first ".INDEX" entry be made that contains the offsets of all the other members?
That could work in a backwards-compatible way (as long as no standard tar utility makes modifications to the archive...), but it's hamfisted. Just use Zip. It's already a well-known format with numerous implementations and already does the job that you want to do.
reply