How to compile and run this? We need a build system! Download and install GNU Make.
When that step is complete:
Type in
make hello
and its done. Now, run via ./hello
See, Too much magic (didn't even have a makefile or Makefile), no standard library, Too constricting, cryptic, too basic. And, because you had to install Make, too complicated. Hits every one of your objections.
ZFS does nothing to protect you against RAM corrupting your data before ZFS sees it. All you'll end up with is a valid checksum of the now bad data.
You can Google more, but, I'll just leave this from the first page of the openZFS manual:
Misinformation has been circulated that ZFS data integrity features are somehow worse than those of other filesystems when ECC RAM is not used. This is not the case: all software needs ECC RAM for reliable operation and ZFS is no different from any other filesystem in that regard.[1]
One snapshot would help because, if EVERYTHING collapses, and you need data recovery, the snapshot provides a basepoint for the recovery. This should allow better recovery of metadata. Not that this should EVER happen -- it is just a good idea. I use Jim Salter's syncoid/sanoid to make snapshots, age them out, and send data to another pool.
I agree that ECC is a damn good idea - I use it on my home server. But, my lappy (i5 thinkpad) doesn't have it.
"The new octopus genome data, she adds, “is pretty convincing evidence that a full collapse happened.”
The findings reinforce the importance of understanding how modern climate conditions are affecting the West Antarctic Ice Sheet, Dutton says. “This is telling us that we need to take this bigger picture seriously.” Continued ocean warming—driven by greenhouse gas emissions—could destabilize the submerged portion of the ice sheet. To lower the chance of another collapse, she says, “We can’t just kick the can down the road and wait to make emissions cuts for another 5 years, another 10 years. It really demands that we do it now.”
Emissions in the modern sense were not the cause of this. But, it happened. Is Dutton making the claim that emissions are the cause now? I'll accept all of Dutton's claims, except that one; there is no basis for that claim. Lower the chance of another collapse? By how much? Would that have actually helped 100,000 years ago? I make the claim that Dutton is suffering from hubris.
You drive a car of type Model Z. Someone, looking at a crash of a Model Z which was going 50 mph, discovers a design flaw that is particularly acute when the car is driven faster than 70. Do you:
* adjust your driving behavior in accordance with whatever bayesian impact the new data has?
* psychoanalyze the person doing the research, or decide that nothing that happens at 50 mph could tell you something about the behavior at 70 to reassure yourself you can ignore the new data?
I do wish that was a reasonable argument. Closer: I drive a "Model Z". In the past, someone discovered a crushed Model Z. Does driving a Model Z more than 50 mph cause crushing?
There are indeed multiple sources of emissions, many not at all needing human intervention at all.
Luckily, we can generally measure natural emissions vs human emissions and find how much of it is being caused by us. Incidentally, due to where various gasses are trapped, many natural looking emissions are still our fault, this is frequently discussed in talks and papers about runaway climate change (note that I mean talks and papers from scientific authorities, not Facebook and fox)
Start with A: Observed Warming and its Causes and move onto b: B. Future Climate Change, Risks, and Long-Term Responses
C02 increases directly increase trapped solar heating.
There are other gases and other factors.
Re: GP comment
* Is Dutton making the claim that emissions are the cause now?
The journalist writing the Science article alludes to the fact that now (present time) Antartic sheet loss is being driven by warming oceans caused by greenhouse gas increases. With no quote marks it's unclear what Dutton had to say on this.
* I'll accept all of Dutton's claims, except that one; there is no basis for that claim.
It's not apparent that is a claim that Dutton made.
* Lower the chance of another collapse? By how much?
See IPCC reports.
* Would that have actually helped 100,000 years ago?
No. Actions taken today would not alter past history.
It's also not the case that ice sheet collapse 100K years ago was related to human or animal gas emissions, unlike today.
* I make the claim that Dutton is suffering from hubris.
You're free to do that. It's not a convincing claim.
Either the journalist writing the article was using Dutton as a source accurately, or Science is not a reputable source of news. This is mutually exclusive.
I took the story prima facie. And, if the story (journalism) is accurate, Dutton is indeed suffering from hubris. Someone brought up the collapse 100,000 year ago in a direct comparison. It was either Dutton or the journalist. If I take Science as an accurate source, it was Dutton. Or it was not Dutton, then Science is not reputable (are they adding implications and misquotes?). If that is the case, why the HN story? HN curated it (that is, HN readers) so I have to give credence to Science magazine (because I give credence "to the crowd of HN contributors"). Again, both sides cannot be argued at the same time.
As to reading the summary for policy makers: the IPCC is a political organization, not a scientific one. Why would its publications that are for policy makers be of interest to me? I need a condensed version of science, not policy. The IPCC doesn't have anything to do with the claim -- (except CO2 causes global warming which the IPCC doesn't actually claim, but does imply, as best as I can tell). Either Dutton made the claim, or Science made the claim -- they have to back it up and defend it. I made no claim EXCEPT that Dutton is suffering from hubris. Which I just backed up and defended.
thanks -- I was under the initial impression that you intended jeeves as a "pythonic make". make isn't a command runner at all. Indeed, it relies on sh for that. It determines the DAG required to bring components up to date wrt dependencies. For example, you may have a postscript file and a pdf. Edit the postscript and you want the pdf regenerated:
my.pdf: my.ps
<tab> command to convert my.pdf to my.ps
Make makes no attempt to generate scripts, or anything like that. In general, make uses file timestamps to determine that my.pdf is out of date with respect to my.ps Make does have default commands that it can use. For example, it knows that executable w can be generated from w.c If I have a directory that contains w.c I can:
make w
cc w.c -o w
Now, because w exists, and is newer than w.c doing make w again does nothing!
You are right, jeeves doesn't do that. Your example reminds me of how I first learnt to use Make; I built my LaTeX stuff from source when in university.
However, dealing with Python mostly in my time in the industry, I scarcely ever had the need to use these particular features of Make. I used it as a task runner, guilty of that, — and that's what I wanted to reimplement in Python.
Even writing in Rust, everything I have to do is `cargo build`, — there is no need to write Makefiles for building the project.
I will consider changing that wording to set proper expectations, but I still feel that for me "a Pythonic alternative to Make" perfectly conveys the use case I daily employ this thing for.
All prices in Canadian dollars. Each of these has a place in horology; meaning; or use for me. The Wilk is a custom piece; there will never be one that is the same. The Casio is for "geek cred". The Orit is for health monitoring. I normally wear two watches. Both the Seiko 5 and the Amphibia have cemented their place in watch history.
They make me happy... these watches are, in general, not looked down upon by "watch snobs".
This story (making an Apple watch into a mechanical) makes me smile... now I want one!
Note that the Seiko 5 SNGZ09K1 is now $281 (Canadian) from Amazon. But the Vostok is $148 now (again, from Amazon).
Sixel is defined for two purposes: the first is to allow display of bitmaps. the second is to allow the definition of characters glyphs (which xterm does NOT have -- due to graphics limitations). If the glyph definition could be done, your bandwidth requirement would be reduced. Back in the 80's we generated custom fonts for PostScript (the Apple laser printer PostScript would cache the glyphs). As needed, the printer would request glyps and these would be supplied by an external driver or box (we called this the "Robin Box" for fairly obscure reasons). This system provided pre-press proofing for many customers (which would include publishers like Ziff-Davis). Please note that the speed of the communication was 9600baud (1000 cps). The image of that printer was 300x300 dpi, with some printers doing 600x600. Sixel would have been good... we used ASCII.
I like sixel -- I use xterm which gives me the option. For everything? No. but if I need a graphic, it is easy enough to use. The alternative for most would be to simply generate PostScript, and run GhostScript to view the results (typically on another system). I have NEVER contemplated watching a video with sixel... I could do it, but the player would be a "labour of love" - I would use a common decoder to produce an uncompressed bitmap (scaling and colour reduction) then convert that into frames of sixel... Just to show StarWars on a 340. But, no urge.
The main issue is that sixel offers the feature. No real reason to NOT have it... and it exists.
Try pbmtoln03, ppmtosixel, imagemagick convert and lsix
sixel is not a protocol: just an encoding. Your idea conflates the two things.
The purpose of the Robin Box? The publishers typically had hundreds or thousands of typefaces. The PostScript Printer? 15 to 50. Since RAM in the printer was limited, this approach allowed the scanning of the target typeface, conversion to outline form and production of dynamic programs executing in the printer. That are discarded but results cached. (and note that
technology is within a period that, in this case, was bounded by RAM space, and typographic conventions -- all of which changed fairly rapidly).
That approach allowed hundreds of typefaces to be used on a single page! With "standard" PostScript; on a printer with only a megabyte or so of RAM available. Sixel is simply a similar tool. You really can't predict how something like would be used if it were generally available.
yeah, i agree that sixel was a reasonable way to implement downloadable fonts in the 01980s, though one that handled line noise and background process output interleaving poorly
(see supdup's graphics protocol for a better design for integrating pixel graphics into a (still retrocomputing) serial terminal. however, supdup foolishly omits any font-downloading facility)
i just think sixel, whatever its merits for the problems of 40 years ago, is a worse way to display graphics today than things like x11, which is itself no shining gem, just not as bad as sixel. also we're sort of stuck with most of x11 for the foreseeable future because there's a lot of software written for it; let's make sure that doesn't happen with sixel
(you point out that sixel is an encoding, not a protocol, which is sort of true, but it has an associated state machine in the terminal, so it's also sort of a protocol, and that's the part that has the poor error-recovery characteristics)
by 'worse' i mean: it requires more effort to achieve an equivalent result; it provides a worse result with the same effort; and there are some results it simply can't achieve that the alternatives can
if you're looking for a puzzle to solve for fun, of course, those are advantages, not disadvantages; but i repeat myself
it's especially an advantage if you find something that was previously thought to be impossible due to laboring under such artificial limitations but turns out to actually be possible despite them
here are some more nontechnical descriptions of sixel that are more correct than any technical description possibly can be
sixel is oulipo programming; encoding your graphics in sixel is like writing a novel without the letter 'e'. btw, a wonderful article about oulipo programming is https://100r.co/site/working_offgrid_efficiently.html
sixel is an art project, not an engineering project
I will show how Make hits every one of your complaints:
(sarcasm on)
in file hello.c:
How to compile and run this? We need a build system! Download and install GNU Make.When that step is complete:
Type in
make hello
and its done. Now, run via ./hello
See, Too much magic (didn't even have a makefile or Makefile), no standard library, Too constricting, cryptic, too basic. And, because you had to install Make, too complicated. Hits every one of your objections.
(sarcasm off)