1,331 karma · joined October 18, 2010
But, even if not labeled as such, I've had similar luck in other venues. Small is beautiful.
One was something he said resembled a wok full of the usual suspects of strong acids. Overnight, the mixture was hygroscopic, so they'd start it heating up in the morning to dehydrate it and increase the concentration. To test if it was ready, they'd throw in a small piece of wood, about the size of a match. If it disintegrated on contact, it was ready. Then you could dip your glassware to clean it.
But, in another lab, they would use a small bottle of hydrofluoric acid at the bench, taking a layer off the glass at the same time. While the dangers of large exposures were well known, he did mention the nerve damage and it being highly annoying and painful if trace amounts got under your fingernails, a somewhat common injury of the lab that everyone simply tolerated.
He thought the latter was a more convenient arrangement.
See also, https://blog.opencagedata.com/post/openstreetmap-in-korea, which relates the situation the same way. It doesn't seem like anyone is hassled for editing openstreetmap from here (and it is quite voluminous), so long as it is not a derivative work of the public surveys.
There is an alternative military-base removed tileset variant, but I believe this is to aid korean GIS users who may not want their application to show sensitive installations, which can generate controversy.
Looking at my Strava relative effort and resting heart rate, the amount of aggregate exercise I get is far superior to my previous exercise habits. While it may take me a net +30 minutes when using non-ebikes to get around in a day, I get something like 90 minutes of total exercise, something I could never justify if I separated my commute from exercise.
E-bikes are extremely quick, depending on the task, they are often less in trip time vs. cars, public transit, or a taxi. But for exercise reasons I tend to ride classic.
I use a cargo ebike for getting my kid to school, but days when I do not need to do that, I use the city shared bikes, often the unpowered ones. I like them both. The latter I use even the same day when I have my cargo bike: it's wonderful to cycle to lunch on a less unwieldy cycle, walk to a coffee shop, and then pick up a bicycle from a different dock to return to the office. All that I choose to carry is a helmet to do that.
It's also a lot more fun than the train/bus (which I also kind of enjoy, my route is somewhat scenic), or driving [and parking].
Example: I have a huge number of perplexity.ai search/research threads, but the ones I share with my colleagues are a product of selection bias. Some of my threads are quite useless, much like a web search that was a dud. Those do not get shared.
Likewise, if I use LLM to draft passages or even act as something like an overgrown thesaurus, I do find I have to make large changes. But some of the material stays intact. Is it AI, or not AI? It's bit of both. Sometimes my editing is heavyhanded, other times, less so, but in all cases, I checked the output.
Looks like this has been the subject of some industry wandering in the last generation:
https://www.urban-transport-magazine.com/en/new-boom-in-the-...
Some were planned for 30-35 years, some for 25 to 30, some models have aged so gracefully they may be refurbished, yet others may have been engineered with roughly the correct obsolescence window in mind as engineering has advanced in the last generation, even in the dimensions of making some things simpler and more reliable (one of the billed advantages of some of the Siemens train mechanisms).
A cursory search suggests that quite a few manufacturers design for light rail car lifetimes of 25-30 years, not forty. These tend to be of European origin, which tracks San Francisco switching from an Italian to a German vendor. I don't see evidence that it's a common practice to significantly extend the tenure of those devices there nor here.
Funnily enough, I see no problems with the Breda trains personally as a passenger. But once they've shaken out the major bugs, the Siemens train reliability is anticipated to be triple or more. It may not make sense to design a traincar for a fifty year term.
Since I experienced 5.25 inch floppy disk era...and even the occasional bernoulli disk...we could simply say: the system had its run, replacement is reasonable. A lot of stuff had changed since then, and not just in storage media.
I think that's an interesting perception of the public. I think of 3M making all sorts of things, generally, I admire the company...in spite of some rather grotesque blunders and bad behavior. But the first thing that comes to mind is adhesive tape (also mentioned in the article)
Contemporary with that era, a Muni bus was burned in the aftermath of the Giants winning the world series. https://www.sfgate.com/crime/article/Knuckleheads-run-amok-a.... This was not interpreted as a stand against Muni.
Waymo cars are perhaps conveniently unoccupied and associated with an organization that can afford a loss. But I've seen very few 2012-like vibes about them (as a pedestrian and cyclist, and much more occasional customer, I basically like Waymo: its reaction speed to my presence is superhuman). They seem to keep their safety records open. I know about that recent unfortunate case involving a cyclist trying to ride tandem with a truck in an intersection, I suspect they'll be changing their programming.
I'm also a big fan of the collision avoidance on my normal Subaru. It's little doubt to me that computers are already mostly better than people at least collision avoidance, where alertness is often the element in shortest supply.
As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today.
I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. This is already true for regular virtual machines or managed postgres machines.
I think the Achilles heel for Crystal is its compilation time on small programs with large dependencies. Note the time to build the entire compiler and standard library is not extraordinary for a large program. It's more like, a small program adding its first few dependencies will find itself pulling in a lot of the standard library to compile, and then will level off in its compilation time.
To illustrate why this may be the case, consider the Crystal feature allowing redefining parts of classes, including ones in the standard library. This is both very useful, and if you think about how it affects features like incremental compilation, immensely complicating.
Here's some practical crystal programs.
This Postgres wire protocol driver is comparable to libpq in performance, and supports a lot of features in the protocol, too: https://github.com/will/crystal-pg/
The Crunchy Bridge CLI: https://github.com/CrunchyData/bridge-cli
I recently rented an even later-model Malibu that only had collision warning auditory alert. Better than nothing, but I'm surprised cars are still made without automatic braking.
For guidelines, see:
https://www.elastic.co/licensing/elastic-license/faq
Text:
I'm using Elasticsearch to put a search box on my cat-picture SaaS product.
This is permitted under ELv2. Meow!
I'm a contractor setting up Elasticsearch and Kibana for my clients to use internally.
This is permitted under ELv2, because you are not providing the software as a managed service.
My cat-picture SaaS product shows view-only Kibana dashboards of analytics on searches and views.
This is permitted under ELv2. The use of Kibana in this case is limited and this does not represent access to a substantial portion of the functionality of Kibana.
I am a Managed Service Provider (MSP) running Elasticsearch and Kibana for my customers.
If your customers do not access Elasticsearch and Kibana, this is permitted under ELv2. If your customers do have access to substantial portions of the functionality of either Elasticsearch and Kibana as part of your service, this may not be permitted.
I provide Elasticsearch and Kibana as a service, where my customers have direct access to substantial portions of the Elasticsearch APIs and Kibana UI.
This use is not permitted under the ELv2. Please reach out to us to discuss your options.
If you have questions about your specific scenario, please reach out to us at elastic_license@elastic.co.
The general plan is: write a SPDK module. We spent some of the last year getting used to using SPDK, for cryptography and workaday disk access, and the first copy-on-access custom bdev (a unit of abstraction in SPDK) is working its way into production now.
https://github.com/ubicloud/bdev_ubi
This copy-on-access happens to use files as the input, but sometime after that, it will be usable for demand-paging images hosted via HTTPS as well.
Some of those code paths will likely learn flavor(s) of replication after that.
It's clever, giving SQLite a lot of power in limited code, important in its conventional application in embedded use cases where fixed costs like code object size and starting database heap size are pretty constrained, and databases tend to be small...but, nevertheless, it's in its own world, there.
https://onlabor.org/california-fast-food-workers-secure-big-...
> Undeterred, labor advocates worked with progressive lawmakers to gather enough votes to pass two more significant pieces of labor legislation. First, AB 102, which was signed into law in July, increased funding for California’s Industrial Welfare Commission (IWC), a long-dormant century-old wage board with the power to set wages, hours, and working conditions by industry. Second, AB 1228, which would have made franchisors jointly liable for labor violations — a long sought-after provision that was taken out of the final version of the FAST Act. According to reports, Governor Newsom led negotiations between industry groups and unions over the summer, and with AB 1228 set to pass this week — the final week of California’s legislative session — industry groups finally caved, agreeing to withdraw the referendum in exchange for a rewritten AB 1228.
> The new bill, which the legislature passed on Thursday, ditches joint franchisor liability entirely and officially repeals AB 257. (As part of the negotiations, legislators also agreed to defund the IWC.) But the bill largely keeps in place the Fast Food Council — with some important changes. First, the government representatives on the Council are reduced to nonvoting members, and the bill adds an independent member of the public who will serve as chairperson, presumably carrying a tiebreaking vote. The Council’s standards would apply to “limited-service” restaurants with over 60 establishments nationwide that share a common brand. But instead of promulgating standards with the force of law, the Council must now submit any standard to the Labor Commissioner, who, upon finding that it is consistent with the Council’s mandate, will then engage in a rulemaking process in accordance with California’s Administrative Procedure Act.
> The bill would set the hourly wage for fast-food workers at $20 effective on April 1, 2024, and the Council may set wages annually thereafter beginning in 2025
This is how the usual suspects get past software interrupts adjacent to the VMM, on the "client" side of things. Getting the driver stack integrated into Linux is no small task and letting it percolate into distributions in common use is necessarily a slow process. SPDK permits getting decent performance and gradual deepening of our functionality while still relying on virtio, which has already percolated.
As I understand it, on the storage side, these cards tend to expose an NVMe interface which is somewhat generic, so you don't see the same kind of driver siloing there. There's a related bit of SPDK and hypervisor functionality, vfio-user (vs vhost-user), but we elected not to use it at this time. They both use a similar shared-memory transport.
Azure is an interesting outlier, a large one, in that their reliance on Mellanox (a subsidiary of nvidia) drivers is documented, so they could be considered in a partnership to achieve the same aim. So you could read the mlx drivers in the same fashion as ena and gve.
I've been watching the technology "vdpa" with some interest to have a shot to also provide pass-through PCIe devices to the guest that do not add such a driver dependency so far outside our ability to influence: Microsoft is going to have a bit more equal a relationship with nvidia than we would as it comes to problematic changes in the Mellanox drivers. But I suspect it'll be some years before that can possibly happen, if it happens at all. It's not easy to get a Connect-X 6 DX card, for example. So, there are many problems for the foreseeable future trying to get into hardware, though I'd like to avoid precluding it.
I liked this blog post in getting a feel for this, but in brief, they're computers plugged into computers: https://www.servethehome.com/zfs-without-a-server-using-the-.... Our alternative is to carve off a core or two instead of plugging a computer into the computer.
Maybe at some future time...I suspect, no sooner than five years from now, but probably, should it come to pass, quite a bit later...there will be some commonality and availability in such PCIe cards and Ubicloud or something like it could consider a tangible development theory around them.
1. Writing a lot of code that runs in the kernel, which is too expensive to be viable, in my estimation.
2. Combining existing kernel features together and living without making medium-sized adjustment for quite a while This was actually my back-up proposal if our experience with SPDK was bad. e.g., get deep into lvmthin and importing/exporting snapshots, but not having a graceful way to add, say, demand paging from an external data store. At some point we'd have to exercise option #1 or jack-knife to something more-like SPDK, which inevitably would be something of a discontinuity in our experience level and the customer experience of the product. I decided we could try to avoid jack-knifing and try to have continuity on SPDK.
3. Paying for extra context switches from user space to kernel space to user space again, at least once, and, sometimes, even additional times, if you need to add a bit of functionality and then use some mature kernel routines. A series of sandwiches.
The polling is wasteful if the server is not doing much, and not bad at all if there's a lot of I/O going on. We'll probably enable and get into tweaking adaptive hybrid polling option in SPDK to quiet things down on machines not running full-bore I/O.
SPDK has a lot in there, getting the logical volume and encryption features, as well as the plumbing for vfio-user, is significant. There are not many options that have this programming, and a programming model to add more. I also found the code and changes to it fairly readable, and the size of the code, e.g. in lvol, approachable.
To my mind, the biggest alteration is who does changes, and why: unless people show a lot (really, a surprising level) of code contribution interest, substantially, Ubicloud staff will make the changes and collect bugs from hosting the software in production. This, alone, is a big departure from how OpenStack has evolved. It was my experience that engineering staff assessing bugs in hosted software they had design responsibility for gave it much of its distinctness. OpenStack's main contributions seems to be consortia in the system integrator space. This distance between operation and design changes makes a big difference in how a project shakes out.
There are some ramifications: one, is that more administratively complex services, like databases, tend to be out of scope for OpenStack, but in-scope for us. Secondly, OpenStack has an interest in broadening the number of mechanisms to support one kind of functionality, to handle varied and complex enterprise installations (that purchase service contracts). We are probably much more cautious about doing this, instead preferring one implementation that covers our target platforms well...and as simply as possible.
Finally, there's era. It's somewhat unavoidable. For example, you would not design a system around IPv6 network underlays in 2010 (OpenStack's formative years), but you might in 2023 (as we did). This simplifies things. You couldn't use SPDK (established 2015, and you might have been brave to rely on it at inception) to have a gentler ramp to implement more advanced block device support and decide: "that's the implementation, unless we replace it totally." Many useful kernel features were developed between 2010 and 2023. Systemd is an obligate dependency of ours, and it has a lot of connections to the more advanced cgroups and namespace feature of Linux...and, brand new in 2010. Bare metal providers were not as advanced in 2010. And so on. Path dependency is inevitable, and we will have a different one, and that will make it a very different device.
So, I haven't written much about what the project "is," but perhaps allowing you to anticipate how it "will be." And why some people found it worth their while to start building it.
REPL, testing, a few key high quality libraries.
In turn:
The REPL: lets you have unified development and operation. Makes it easy to record and review methodology when taking administrative action.
Testing: both made more necessary by the dynamic typing of Ruby, but more importantly, without disturbing the program under test much you can inject any input, any fault, nearly anywhere. In this way you can accrete invariants guarding against a large class of bugs encountered in production into the test suite, a form of retained learning.
The libraries: Sequel, Roda, Rodauth, part of the Jeremy Evans universe. They're very good by any standard, not even as confined to the Ruby world. The maintenance level on those is something I aspire to, but have never been able to duplicate. I did copy the 100% line (and later, branch) coverage project practice from this, though, in Citus Cloud and later projects, and it seems like a good thing, though not for the reasons people might anticipate.
An anti-requirement: control planes often have fairly lax performance needs relative to operation value. A few crucial loops, like monitoring, may indicate something with more efficient machine code. But mostly it's a fancy SSH client with quite a few tests, and some carefully designed concurrency patterns. Of the above factors, I'd say the REPL is the most dispositive for why I tolerate the performance and parallelism ramifications of Ruby, though, they all add something to my decision to use it for this.
This design theory is the fourth in a progression for me, though there are other clades by now. Heroku Postgres was the first, Citus Cloud was the second, Crunchy Bridge is the third, this is the fourth.