I'm not going to lie, the comment about "if they can use git" is the core of my problem with the arctic storage. I'm still wondering what the point is other than to make some meta point about how committed github is to preservation
_It will also include works which explain the many layers of technical foundations that make software possible: microprocessors, networking, electronics, semiconductors, and even pre-industrial technologies. This will allow the archive’s inheritors to better understand today’s world and its technologies, and may even help them recreate computers to use the archived software._
There's no git usage, they're just storing a snapshot of each repo's current HEAD in a TAR file (and then compressed and QR-encoded).
> The snapshot will consist of the HEAD of the default branch of each repository, minus any binaries larger than 100KB in size—depending on available space, repos with more stars may retain binaries. Each repository will be packaged as a single TAR file.
In the link you post it states "piqlWriter: data writtenas high-densityQR codesEncode binary data to 2D barcode (apply Forward Error Correction)Modulate light using a Digital Micromirror Device (DMD) to project the barcode on the film."
Haha, yes, I have this image in mind of future scientists trying to understand the mess the git CLI is! I'm sure they will have a bunch of theories in which git is considered a religious relic from past humans, used to summon some gods by writing weird incantations, that's already how it feels to me some time :)
The data-model, however, is not. It is actually a very smart, mathematical (cryptographical) tree-structure[1].
I'm pretty sure some far future generation will be able to figure out the math behind a "git database". I'm actually more confident they will be able to do so, than your average "excel" or "winrar backup".
--
[1] I really started liking git and understanding what it all is about (and how to use the weird commandline --flags - or was is -flags or -f or -F or flags) after reading the Git From the Bottom Up book: https://jwiegley.github.io/git-from-the-bottom-up/
My understanding is that the vault also includes instructions on how to access the stored projects. I would guess this has to at least explain the minimum ability to replicate git or understand git's format?
The market is reactive to relatively short-term inputs. I'm looking at a few things that are causing the jump:
- Some of it is inflationary as others have pointed out. There's a lot of money entering the system right now, and markets tend to go up on that
- Some of it is short sellers realizing gains from the last month and exiting their trades (the effect of closing a short causes markets to rise)
- Some of it is psychological reactions to dropping death estimates, and concurrent optimism that things will go back to "normal" soon (or at least sooner than previously thought)
What the market did 12/21/18 is sort of irrelevant
I'm not an expert, but most government agencies are allowed to charge reasonable fees for access to their data. I don't know if this qualifies, but it at least seems like a possibility, especially if it's transparently just passing along their costs in the form of AWS' own cost structure
OMNY is neat. You do not need to turn your phone's screen on to use it, and it works for a while after your phone's battery dies.
It is still slower than what I'm used to in Japan, where people have been paying for transit with their phone since 2001 or 2002. (Tokyo also went from 50-ish pilot stations to 500 production stations in just a few months. In New York, I think 2023 is the estimated completion date?)
At one job we actually had to give up on take-home challenges basically because a good, humble junior was indistinguishable from a good, clearly-thinking senior
This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it).
The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important thing to do.
My engineers know that they're expected to do that one project to completion, and we loop in other stakeholders (marketing, sales, QA, etc) progressively as we approach completion. Admittedly I work at a company of 20, but it works remarkably well, despite the absence of a "schedule"
You meet the PM/PO. They want to do Scrum, standups, retros, grooming, poker planning the whole thing.
Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets.
The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar.
By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy.
I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).
Wow, I wish the Fortune 10 company I work for had this kind of insight! The "agile" process I work under is causing horrible outcomes. It's basically a sweat shop operation is what it really is. I'm a tech lead and am always fielding questions like "why did this take so long?" It took so long because there was unexpected difficult A, B, and C, two of the four guys on team are mid-level devs and not senior level, and so I worked a third night this week to try and pull this off. The sprint plan never makes it past 1-2 days each sprint and then I catch a bunch of righteous indignation with phrases like "you committed to this" and crap like that.
"Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven.
"Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart.
The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?
