I think the bar for what constitutes unacceptable outside of work behavior changes significantly as you move up the responsibility ladder. Once you are in any significant leadership position where credibility and moral authority matter, doing things that land you on the front page in situations that make you look highly partisan, or immoral, or just plain stupid, in the eyes of much of your constituency - employees, customers, or community - is a real tax on your ability to lead. It justifies firing. And, to be clear, if Gow really thinks his porn appearances don't impair him in his job as university Chancellor in small Wisconsin city, he's probably also too social judgement impaired for the job anyway. Chancellor is not a back-office job.
> The COVID devastation is also about long COVID, and even people who had COVID but either recovered “fully” or never displayed symptoms. None of this is over, and we are so, so fucked.
SARS-CoV-2 is certainly with us to stay, so in that sense it's not over. But beyond that, I don't see how "we are so, so fucked" as you say. Covid is no doubt taking a small nibble out of life expectency, and yes there is some long Covid still taking its own nibble out of productivity and life satisfaction ... but it's not that big a part of the big picture. Covid is killing less than half as many people in the US at this point as lung cancer, and those deaths are overwhelmingly amongst the elderly. I don't want to be overtly callous, but knocking a few years of life off people well into retirement is hardly going to bring the country to its knees. There are essentially no Covid deaths among people under age 18, and among the working age population, cases requiring hospitalization or leading to long term debilitization are rare.
Those who suffer, of course, suffer. We shouldn't be unsupportive of them in their trials. But Covid as a public health crisis is largely over.
Not necessarily. Black locust (Robinia psuedoacacia), e.g., is one of the faster growing hardwoods in North America, but produces very hard, dense, and strong wood.
Without question, if you've got a tractor you can rely on, I would get a PTO-driven generator for backup. Even a little 30HP diesel tractor will power a 15kw generator, which is big enough for almost any household as backup. Farms typically have the grown version of these (if your small tractor is 100hp, as is the case for farms around here, no reason not to have a 50kw backup generator).
I don't see how this conversion makes much sense. He started with a generator that was junked because the ICE was shot. He could have replaced that ICE with an off the shelf 4 cycle engine for under $1000.00. Instead, he's got a car that even as junk was worth half what the new engine would cost, with the space requirements that come with a car, the investment in electronics and build, and the net result is a junked nearly 200hp car running an generator that can only use maybe 10HP tops. A great job of McGivering up something, but I can't imagine why anyone would do the second one.
I'm not sure I understand what you're saying. Are you saying that these exchanges are trading at prices to a precision of 10 ^ -10 dollars (or other currency)? I saw private exchanges pricing to hundredths of a cent (a long time ago - it's been a decade and half since I worked on Wall Street or in the City) or yen, but never any finer than that. Even then, all transactions were recorded in whole cents.
I'm sure you've done your homework, and I'm long out of the finance business, but even so, I think the applications where this matters are, as financial applications go, very unusual.
I'd like a report back from TigerBeetle on how many applications they actually support where the high order 64 bits are nonzero. I would note that the entire US GDP is less than 10^15 cents, and that 2^64 accommodates just shy of 10^19 in signed integers. So, even if your database had a justification for thousands of a cent transactions (not intermediate results, but recordable transactions), you'd still need to have transaction entries larger than the US annual GDP to roll over into the high order 64 bits.
TigerBeetle may have made the right choice for some market, but I predict that there are vanishingly few sales calls where this becomes an important selling point, unless it's potential customers wondering why they are wasting all those bits and checks for a whole lot of freakin' zeros.
I'm not a collector, but I'm tempted to bid on this book. It's remarkable to imagine the effort the original owner had to put in, over a couple of decades, to collect all those signatures, and it really is a who's who of the Manhattan project, and of course, of the bombing itself.
Well, the details are at least somewhat impeached by the fact that she got the date wrong (or you did, in your comment). There was no Trinitite to be had at Los Alamos until 1945.
I'm happy for you if that's working out in your enterprise. It was not our experience in the time frame we're talking about (VB was sunset over 20 years ago), and frankly it was not our experience 5 years ago - when we were running skads of applications on Citrix servers so we could have absolute control over the "client" runtime environment, and have the actual on-the-glass experience be thin client.
Of course, if you want to twist VB, or Delphi, or any of the client-server construction sets into pretzels, you could build a well-factored system. And yes, your data has to scale to your system size, regardless of the architecture. But if you use any of those tools (the article was about VB, after all) as designed, you cannot escape the problems I outlined. Your business logic will be either entirely on-client, or split between the client and the database, and it won't be stateless. You will have database connections and transactions spanning thousands of client processes directly to the database, with all the scaling and contention problems that introduces. And you will have an update problem, because updating business logic requires you to push changes to thousands of client machines, which may or may not be available and updatable when you go to deploy your new version.
Can you still build a system, and operate it? Sure. A lot of us did. For small to medium scale systems, it was manageable. But there is a reason we abandond 2-tier client server 20 years ago. While it made building CRUDy business applications vastly easier for the developer, it was a systems nightmare.
(It also led to crappy user experience for any application that wasn't itself inherently a CRUD record keeping job, because it inhibited application designers from thinking of the application as anything other than CRUD. But that's a different argument for a different day).
Well, that, and all those wonderful apps were inherently client-server architectures, with the business logic on the client. Nobody ever built a properly factored, with stateless layering, and high-end scalability on such an architecture. Just trying to keep 1000 clients in sync, so your business logic remained consistent could drive you to distraction; in a truly distributed product with tens or hundreds of thousands of clients, it was impossible.
Probably. But what seems much more interesting is to have a spatial model pre-seeded in the LLM, so that it "attaches" language to that as part of its training. Ditto for other models of the world we want the language module to be able to draw on and reason with.
Obviously, you didn't read how it is intended to work. Baking the rock gives them a stream of nearly pure CO2, which can be sequestered underground. The powdered rock then efficiently captures CO2 from the air (where it is of course, very low in concentration). That CO2 can then be baked off, sequestered, and the rock cycled to the air again. In an industrial plant, you'd have a continuous process of rock being baked, exposed, baked again, with a continous stream CO2 being sequestered geologically.
It's interesting that discussions of this process don't mention the potential to combine the carbon sequestration with, say, nuclear power generation. This process basically requires a lot of heat. So, maybe build high temperature gas cooled reactors to provide process heat for this process (which is inherently highly interruptible), used to offset continued use of petroleum in applications where electricity just doesn't work (commercial aviation, e.g.), with the option to switch to electrical generation when renewables fall short.
I'm really thinking of the energy scaling. Suppose you want to use such a technology to offset burning oil for some purpose. Even for highly efficient processes, you're going to get generate a ton of CO2 for a MWh of usable energy. You're then going to use 2 MWh of electrical energy to recapture the CO2. So, you've tripled the energy we need to produce for that process. That's really raising the bar on carbon neutral energy production.
There are no energy free ways to resequester atmospheric CO2. If you accept that we will have to do so to meet the world's climate change goals, then the question is really, how energy efficient can you make your process, and where can you get carbon-free energy. This company has a credible approach, although as soon as you look at any of the mechanisms being considered, the scaling problem is daunting.
It would be interesting to see someone dig into the differences between the capture of language and culture, and control over how it gets fed back into cultural discourse, that we fear corporations achieving with commercialized LLMs, and the control pre-internet publishers had (and to a certain extent, still do), over what content, and in what format, language was disbursed and distributed. I am not at all certain that having your work used to train LLMs is a bigger threat to writers ownership of their work than publishing houses were and are.
I also suspect that if we had an effective mechanism to prevent use of copyrighted work in training, it would necessarily behoove an artist to opt their content out. Will you really want to be excluded what may well become the canonical mechanism for searching and generating language?
Seeing that old Friden mechanical calculator under it's cover take me way back. We used them to do basic statistics on data sets in an NSF summer research school I attended after my high school sophmore year. What a sound a roomful of them could make.
At the time there was one computer on the college campus where the program was hosted - all batch, all punched cards, of course, and too valuable to be used for mere number crunching of undergraduate research. By the time I matriculated a year later, the physics department had its own PDP 8, and we did our number crunching on data sets punched onto paper tape, on that. Given the challenges in getting a data set properly punched and the cost of debugging, I'm pretty sure the PDP only saved net people time if you had to run the same computation at least several dozen times.