145 karma · joined November 14, 2021
Can't find the episode name but it was a rainy rainy night (what else). I think the set was the interior of a small fishing boat.
X-Files filming happened all over Vancouver for years. People didn't pay excessive amount of attention to the actors and guest stars when they were at hotels, restaurants etc. Unlike some cities.
Identification of the risks including the likelihoods and hazards is pretty good. I like the notion of contrasting opinions included in the report.
But the big thing missing is mitigations: what can they do about training, about recruiting, and especially about "industry" investing in compilers? This report says nothing about ways to assure continued usability of Fortran-based codes in the next 10 or 15 years. It just lists risks. What can they do to improve the capability of GPU compilers, CPU compilers, training or staff development?
And, setting Fortran aside, what are the plans to assure continued capability in supporting and developing all of their codes, in whatever languages, in the next 10 or 15 years? This evaluation might well be replayed for CUDA, Python or Julia in the next 5 years.
The US budget for supercomputing must be in the $2G to $5G per year range, yet it seems the notion of planning a software strategy for supercomputing is not achievable.
Yes.
The relatively warm winters that allowed pine beetles to survive (I think it takes 10 days at -20C to kill them; ymmv) lasted a few years. It may still be going on.
The pine beetle is one of the supporting arguments for climate change---irrespective of arguments about cause. And it is not about drought.
So I conclude your comment is not relevant to mine.
Fueled by dry trees and brush due to drought with fires started by lightning strikes is a little closer to the literal truth.
An average temperature rise of 1.5C over the last 50 or 100 years is climate change.
A regional drought lasting 5 or 10 years is...a drought.
"forking" netbsd established competition in the "free" BSD space by OpenBSD and FreeBSD. The FreeBSD system in particular was the basis for thousands of commercial products.
This is a lesson a lot of software people haven't yet learned. Bad UI, bad operational experiences, insufficient logging to resolve issues, un-fixable code because it's too complicated, and so on. But they use git.
The other term of art for this concept is "system engineering", in the aerospace sense. There are a lot of good texts and courses.
One example: Wesson: System Analysis Design and Development, Wiley, 2005. ISBN-10 0-471-39333-9
OpenBSD prohibits this except when code is run from a partition that permits it by means of a mount flag. Otherwise you get a core dump.
And all the partitions are largely an availability feature: if errant code fills up /var/log then /home is still usable.
See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8747021/ for a review article.
Summary: there are many risks, from menu fatigue, energy consumption vs expenditure (e.g. exercising), adverse effects of space travel from microgravity, long-term radiation exposure, metabolic stress, and so on.
"grep" arxiv.org in the "computation and language" section for interesting articles. There is a lot going on. Some is lightweight but much is insightful.
Look at a Dell or HP server configurator website to see why.
If you "only" need GPU, a craigslist search should find a less expensive 2 or 3yo server to plug your latest GPU into.
It only had step 11.
We used to run "Dell" storage and tape (rebranded ADIC changer and Quantum/IBM drives). A tape changer would autoload tapes under command of the backup software. It would run overnight, automatically changing the tapes two or three times, as required, without issues.
Restore was another problem, mostly the fault of the software.
(You can occasionally get away with slightly lower feed speed -- the drive will write "invisible empty data" to keep the motors running and tape movement going -- but that cuts into capacity of the media in unpredictable ways. And eventually the drive decides it is facing data starvation and stops writing. The result of that is a few seconds of tape repositioning to restart the writes.)
And there is no avoiding reading all the data on the tape when rewriting to another tape. The media is cheap after all. And therefore "discard" is largely pointless, unless it's 90% or more of the data.
And even vi gets fixes these days (Fixed handling of escaped backslashes in vi(1) ex_range).
I've been using klong as it is small, quick to build and has good intro, reference and quick-reference.
One downside is somewhat memory limited.
"Andromeda Strain", directed by Robert Wise, 1971.
The sequence where the specialists are "sterilized" before entering the most secure levels of the lab are best.
Robot voice: "Please enter the chamber and be sterilized."
Dr Leavitt (played by Kate Reid): "I'd rather be decontaminated."
You will have to prove a lot of "facts" to win that lawsuit. Especially since your social number(s), email, phone, whatsapp, etc are all public info already.
Recall a few years ago an uneducated hacker ("script kiddie") got part way into a CRA website and they took the whole website down for a week. (The attacker was caught, and prosecuted iirc.)
(In some countries/companies this function is called the comptroller or the controller.)
Print quality is good; the image does not bleed and the paper does not warp from "wet ink" syndrome.
But it is expensive.
And it has the oppressive "login to HP website to print". Nope, I avoid that.
Pro tip: decline auto upgrade of the "HP Smart" software; one day HP will "update" your software to require login before printing. The workaround is to remove that software and load the "enterprise" class packaged software.
Yet you are not prepared for an important consequence of the results of your research.
Perhaps you should consider changing hobbies.
C++ is just too big and slow to compile.
Rust has a reputation of complication and steep learning curve.
Go has the same issues as Node.js -- uncontrolled import of hundreds of weird and unknown and unknowable libraries.
V is opinionated, has a single definition of correct formatting, compiles to fast-enough C, has numerous handy features, is sensitive to multiple platforms and architectures, and has lots of usefully comparable code to learn from and borrow from.
V is not scientific enough, but that depends on the libraries you choose not the language itself (the scientific lib vsl is quite different from the tensor lib).
There are a lot of wanna be scientific languages (Chapel is a particularly good example) but the usual problem is that no-one adopts them because almost no-one else adopts them. Cray Fortran introduced Co-Array Fortran which got some traction but it is almost unheard of both inside and outside the Fortran community. (CAF abstracted from OpenMPI so you could write code that ran on hundreds of CPUs without really caring how or where the code ran.)
Maybe chatgpt or other LLMs will enable effective cross-language translation making it easier to move between interesting language communities. Modulo translation errors of course.
Authors in larger organizations are more editors than authors, and documents require submissions and detailed reviews by many different people. A management feature would be summarizing comments (RID - review item discrepancies, AI - action items, etc) and status of each comment; plus document deltas; plus document delta markup (change-bars in the margins of presentation versions like PDF).
Another feature would be support of document hierarchies, where changes to one doc invoke functions/procedures/status changes on subordinate docs.
Another feature would be tagging a set of matching documents as a "release" set.
The enterprise products support much of this. And the price is not small.
The results are very interesting and generally follow the rule that bigger hand-optimized code can be faster code.
A slightly different take: there are a couple of categories for system changes: (a) adaptive changes to respond to a changing environment or requests for new functions, and (b) corrective changes which fix bugs (bugs of any age).
Examining a proposed architecture with these two categories in mind might help. As long as changes are correctly categorized and therefore the scope of changes matches, your architecture may be seen as better or worse. Or more or less survivable.
And on yet a completely different perspective: choose between two or three possible architectures. If you haven't got a choice then you need to fix that.
But annual "support" fees are still 20% (or is it 25% now?) of list price.
I got a good laugh out of that....
The best line, like all news articles written to a standard style, is the last one:
"The report showed he reviewed 63 spying warrants, 49 of them the most serious kind, a Type 1, which lets an agency carry out an otherwise unlawful activity in order to collection information about a New Zealander."