Remains to be seen. That's what they want, but it's never been done before. (edit: clarity: they do NOT want to replace them after each flight.)
They're currently experimenting with things such as actively cooled tiles (which I presume were installed on this ship, since they were on the last two).
I personally think the likely best case is that they'll have to go over the ship and replace some here and there before launching again.
Even if they don't get to a no replacement....they still already have a massive improvement over Space Shuttle. The Space Shuttle basically every tile was unique, and and the pattern was different between the different orbiters. A good bit of the months of refurbishment of the Orbiter between flights was heat shield repairs. SpaceX has already shown from when they completely retiled one of the ships. they have cut down the time to replace a single tile down to minutes instead of the hours it took with the shuttle. The Tiles are also alot more standardized so they can be more mass produced than shuttle tiles.
I think there are still a few unique tiles on Starship around joints and such IIRC, but either way, the number of tile types is much smaller for Starship.
To my thinking, the sane sequence will be launch; catch; survey and maintain (heat shield and other items); and then launch again 24 hours later if everything checks out.
And that will be an absolutely massive improvement over what we have today, let alone what we had with the Shuttle.
While that is certainly true, the idea that they can so rapidly decimate your data without the possibility to restore is still terrifying if that's your only copy of that data.
They should have to hold it for at least 90 days. In my opinion, it should be more like six months to a year.
In my mind, it's exactly equivalent to a storage space destroying your car five days after you miss a payment. They effectively stole and destroyed the data when they should have been required to return it to the actual owner.
Of course, that's my opinion of how it should be. AFAIK, there is no real legal framework, and how it actually is is entirely up to your provider, which is one reason I never trust them.
The post suggests that even if AWS’s policy had been to hold the data for a year, the same thing would have happened, because they deleted the data early due to operator error.
Similarly, a physical storage company can totally make a mistake and accidentally destroy your stuff if they mix up their bookkeeping, and your remedy is generally either to reach an amicable settlement with them or sue them for your damages.
> When AWS demanded this vanished payer validate himself, I pointed out that I already had my own Wise card on file—the same card I’d used to pay before the payer arrangement, kept active specifically in case the payer disconnected while I was traveling or offline
My fear of this sort of thing happening is why I don't use github or gitlab.com for primary hosting of my source code; only mirrors. I do primary source control in house, and keep backups on top of that.
It's also why nothing in my AWS account is "canonical storage". If I need, say, a database in AWS, it is live-mirrored to somewhere within my control, on hardware I own, even if that thing never sees any production traffic beyond the mirror itself. Plus backups.
That way, if this ever happens, I can recover fairly easily. The backups protect me from my own mistakes, and the local canonical copies and backups protect me from theirs.
Granted, it gets harder and more expensive with increasing scale, but it's a necessary expense if you care at all about business continuity issues. On a personal level, it's much cheaper though, especially these days.
I would suggest your CTO needs some gentle reminders about risk management and how the cloud really works.
If your boss is that daft, its probably a sign to bail out. Remember to do your own personal due diligence. Due dill is not something that you just do for someone else: do your own! Do your own personal risk assessment. If code was lost, who would be found accountable? You or them?
Unless github closes the account, or a hacker gets access, or a rogue employee gets mad and deletes all, or some development accident results in repo deletion, or etc etc.
Company was founded by "visionary" CEO that is an sculptor and doesn't understand tech.
Most crucial employee is young guy hired right out of college.
Company now has 50+ developers, but the critical software is still made by that guy several years later.
Critical guy still get recent graduate salary, notices he is actually the most important person in the company, and asks for a raise.
Company denies his raise. He quits. Company hire a bunch of developers from cheap third world countries to replace him...
Company learns: 1. All software guy made a bit before he asked for a raise was on his personal, not company github. 2. The software is in other programming languages, not the one the company uses normally. 3. Everything the guy wrote since he joined the company, is extremely difficult to maintain, guy is a genius and all his code is correct, clean and well made, but his thought patterns and how they end in the code are just too different, and all people that worked with him before also were geniuses and didn't care the code was "crazy".
Note: the "other geniuses" mentioned above, also quit when other companies made them great offer and the stingy employer refused them a raise too.
If only 10 out of 100 of your investments make it, does it matter if one of the 90 failed because of lacking backups? Their risk strategy is diversification of investments. Not making each investment itself bulletproof.
Yes, it is in effect a gamble. The issue is that this strategy doesn't really prove profitable for the majority of VCs. Less than 30% of VCs get to a unicorn or IPO deal. 46% of VCs don't profit at all. This is as per the recent post "(Only) half of senior VCs make at least one successful deal.". I am even ignoring the ones who drop out and don't contribute to the active statistics.
The strategy is about as silly as having ten babies and expecting that one of them will make it. It is what you would expect out of the worst poverty-ridden parts of Africa.
An alternative is to select and nurture your investments really well, so the rate of success is much higher. I'd like to see the script be flipped, whereby 90% of investments go on to becoming profit making, secondarily with their stable cash income being preferred to big exits.
They often only have a binary that you would have to reverse engineer. Source code gets lost.
To step outside just utility programs, the reason why Command & Conquer didn't have a remaster was:
> I'm not going to get into this conversation, but I feel this needs to be answered. During this project of getting the games on Steam, no source code from any legacy games showed up in the archives.
> And the people using it multiple times a year delete it afterwards?
The people wouldn't, but in the environments I'm thinking of, security policies might.
What you're leaning into is a high-risk backup strategy that would rely mostly on luck to get something remotely close to the current version back online. It's pretty reckless.
> The people wouldn't, but in the environments I'm thinking of, security policies might.
In environments that go so far (deleting local checkouts of code out of security concerns), I bet they do have a mirror/copy of the version controlled code.
Devs clean up their workstation sometimes. You can get fancy about deleting build artifacts or just remove the whole directory. Devs move to new machines sometimes and don't always transfer everything. Devs leave.
Software still runs, and if you don't have the source then you'll only have the binary or other build artifact.
Popularity != importance. There is plenty of absolutely critical FOSS code that receives very little maintenance and attention, yet is mission critical to society functioning efficiently. And the same happens in organizations too, with say their bootloader for firmware of hardware products.
Over the long term, the odds reach 100% that it won't be checked out. That's because people mostly only work on newer projects. As for mature older projects, even if they're running in production, cease to see many/any updates, and so they don't get cloned on to newer laptops. This doesn't mean that the older projects are now less important, because if they ever need to be re-deployed to production, only the source code will allow it.
If the repo is on GitHub and two or more developers keep reasonably up-to-date checkouts on their local computers, the “3-2-1” principle of backups is satisfied.
Additionally to that, if any of those developers have a backup strategy for their local computer, those also count as a backup of that source code.
CTO explaining that to the CEO when your source code is completely gone:
CTO: "I know our entire github repo is deleted and all our source code is gone and we never took backups, but I'm hoping the developers might have it all on their machines."
CEO: "Hoping developers had it locally was your strategy for protecting all our source code?"
CTO: "It's a sound approach and ticks all the boxes."
Technically true, but only if we consider dev checkouts as "backups". In the majority of cases they probably are, but that's not guaranteed. The local repo copy could be in a wildly different state than the primary origin, a shallow clone, etc... While the odds of that mattering are very low, they're not zero. I personally prefer to have a dedicated mirror as a failsafe.
LMAO. Must be one of those MBA CTOs. At least mirror the crown jewels to bitbucket, Tarsnap, or somewhat else that has 2 weeks - 3 months worth of independent copies made daily.
If not MBA, the problem may also stem from the gradual atrophy and disrespect shown towards the sysadmin profession.
Exactly. Techofeudal overlords can switch off all "your" stuff at any time. Always have a personal and a business disaster recovery plan including isolated backups (not synchronized replication) on N >= 2 separate services/modalities.
Options to consider for various circumstances include:
- Different object storage clouds with different accounts (different names, emails, and payment methods), potentially geographically different too
- Tarsnap (while using AWS under the hood but someone else's account(s))
- MEGA
- Onsite warm and/or cold media
- Geographically separate colo DR site, despite the overly-proud trend of "we're 100% (on someone else's SPoF) cloud now"
- Offsite cold media (personal home and/or IronMountain)
How do you distinguish a mirror from not a mirror on GitHub?
I often have my git configured to push to multiple upstreams, this means that basically all of your mirrors can be primaries.
This is a really good part about GitHub. Every copy is effectively a mirror, too, and it's cryptographically verified as well, so, you don't have to worry about the mirror going rogue without anyone noticing.
I use GitLab locally and push only to that. GitLab itself is configured to mirror outbound to the public side of things.
In a collaborative scenario, doing it that way makes sure everything is always properly synchronized. Some individual's lacking config can't break things.
IMHO Lawyers get creative, a github account can show a ton of work activity, nda voilations, etc. Your "private repro" is just a phone call away from being a public repro.
> Granted, it gets harder and more expensive with increasing scale, but it's a necessary expense if you care at all about business continuity issues. On a personal level, it's much cheaper though, especially these days.
I don't go as far as "live mirror", but I've been advocating _for years_ on here and in meatspace that this is the most important thing you can be doing.
You can rebuild your infrastructure. You cannot rebuild your user's data.
An extended outage is bad but in many cases not existential. In many cases customers will stick around. (I work with one client that was down over a month without a single cancellation because their line-of-business application was that valuable to their customers.)
Once you've lost your users' data, they have little incentive to stick around. There's no longer any stickiness as far as "I would have to migrate my data out" and... you've completely lost their trust as far as leaving any new data in your hands. You've completely destroyed all the effort they've invested in your product, and they're going to be hesitant to invest it again. (And that's assuming you're not dealing with something like people's money where losing track of who owns what may result in some existence-threatening lawsuits all on its own.)
The barrier to keeping a copy of your data "off site" is often fairly small. What would it take you right now to set up a scheduled job to dump a database and sync it into B2 or something?
Even if that's too logistically difficult (convincing auditors about the encryption used or anything else), what would it take to set up a separate AWS account under a different legal entity with a different payment method that just synced your snapshots and backups to it?
Unless you're working on software where people will die when it's offline, you should prioritize durability over availability. Backups of backups is more important than your N-teir Web-3 enterprise scalable architecture that allows deployment over 18*π AZs with zero-downtime failover.
Assuming that code is actually present in your app, env vars can hold more than 255 characters. Easy buffer overflow to trigger. Use length-bounded copies and concats...
That's just off the top of my head; I've not written in C in a while.
Yeah, that is not a helpful attitude to take when it comes to this sort of thing. If nothing else, a super-long home path can crash your app and leave your user scratching their head. In other words, this is a bug (as is the fact that paths are not necessarily limited to 255 characters in the first place; see the PATH_MAX constant, I think it is?).
As to what could be accomplished with an overflow? I don't know; I'm not in security, and I don't sit around thinking of possible uses for various bugs when it comes to compromising systems.
Perhaps the most important thing to realize, though, is that you're distributing software publicly. Your security situation may not be the same as your user's security situation. Assumptions should not be made.
As long as you’re fixing that bug, you should do it right. If the return value from snprintf if more than 256 but less than a few GB then you should malloc a buffer big enough to hold the string and then call snprintf again with the new buffer. Only if that or malloc fails would you print an error. (It’s really a shame that the C standard library requires so many extra steps to do things correctly; this ought to be way easier.)
Signing up for services with a notoriously complex pricing structure, under the auspices of a company that is infamous for auditing its customers and forcing more money out of them on the basis of technicalities under threat of legal action, seems... unwise... to me.
(an AWS bill has about 10 pages of items you get charged for, with only 3 line items explained what they are, and even then, not why you get charged. GCP is better, but not by much (let's call it about 4 pages), and Azure is again better, but also not really (2 pages). AND they're all at least 10x as expensive as colo or dedicated hosting. Yes, 10x. People will deny that, and then you look at charges for data traffic, and conclude that if you use a lot of data traffic, it'll quickly start being more than 10x more expensive. And even cheap dedicated is only cheaper than a box in the corner of your closet for 6 months, maybe a year)
No, it's not. You can do very basic selection with resistors, but you can't get above 5V (or more than a couple of amps IIRC) without using the actual PD communication protocol.
Do you think that "being competent at design" is the only requirement for designers?
I would say that it's more important to be competent in determining how design is going to be understood and used by users in their individual workflows. Few are more competent to judge that than the users themselves.
I'm pretty sure most folks have seen and experienced the negative impacts of designers changing things for the sake of change (or to justify their paychecks).
Being competent in determining how design is going to be understood and used by users IS being competent at design.
There is a massive amount of bad design out there — made by designers. There is a large amount of bad software implementations. By programmers. And awful chairs, food, and ...
Not really that odd. It's easy to live without IPv6 until someone creates the IPv6-only killer app, and that makes it... not worth the hassle for most folks.
I'm in a moderate-to-high technology area in the grand scheme. They laid fiber here roughly two years ago, and lit it about a year ago, whereupon I immediately subscribed.
They don't offer IPv6. At all. That should tell you just how unimportant IPv6 is perceived as outside of its core cadre of proponents. Note that this is not a commentary on how important it actually is; just on perception.
> It's easy to live without IPv6 until someone creates the IPv6-only killer app
This was a few years ago, but the majority of Danish ISP wasn't offering IPv6, because "there's is no demand from customers". Well, the customers also aren't demanding IPv4, they are demanding internet access. How you deliver it is not interesting to anyone but a small niche segment of the market. If you could somehow make it work over IPX, then 95% of customers would be fine with that, it's not something they care about.
It does not work like that, what you get is big deployments using ipv6 and some strange ipv4 setup so there are more and more clients using ipv6. On the server side you will start to see more and more clients using ipv6. About 40% of our customers use ipv6. They can still access ipv4 though it is just that their network provider prefers having them on ipv6.
Ip version is not a selling point, unless you are on the server.
Not just a network provider preference. It is an OS-level preference in most consumer hardware today. (The "Happy Eyeballs" protocol, among other things. OSes will send IPv6 first, then after a delay send IPv4 and after that favor whichever one is "quickest"/"healthiest".) It's also a natural preference over things like STUN/"UPnP" to avoid NATs, especially CGNATs.
Most consumer networks are IPv6 by default. Most cellular networks are IPv6-only/IPv6-native today with big DNS64/NAT64 gateways to the IPv4 web. Most consumers don't know or care, they just use IPv6, daily.
A lot of the holdouts on IPv4-only traffic are corporate traffic. A lot of corporate traffic acts like it wants a separate internet anyway, and a lot of companies hoarded IPv4 spaces for long enough that they don't see the increasing costs of IPv4 addresses hit their bottom lines yet enough to care. It's a fascinating dynamic. Maybe corporations will just buy the remaining IPv4 internet entirely and keep it as their own separate but not equal network.
From skimming the article, it seems that this is a munging of the terms in directions that just aren't meaningful.
I've had the following view from the beginning:
- Batches are groups of data with a finite size, delivered at whatever interval you desire (this can be seconds, minutes, hours, days, or years between batches).
- Streaming is when you deliver the data "live", meaning immediately upon generation of that data. There is no defined start or end. There is no buffering or grouping at the transmitter of that data. It's constant. What you do with that data after you receive it (buffering, batching it up, ...) is irrelevant.
No, it really doesn't. The definition of "streaming", to me, can be boiled down to "you send individual data as soon as it's available, without collecting into groups."
Batching is, by definition, the gathering of data records into a collection before you send it. Streaming does not do that, which is the entire point. What happens after transmission occurs, on reception, is entirely irrelevant to whether the data transfer mode is "streaming."
Most streaming does some batching. If you stream audio from a live source, you batch at least into "frames", and you batch into network packets. On top of that you might batch further depending on your requirements, yet I would still count most of it as "streaming".
Only if you ignore that streaming streams data in records. The creation of a record (or struct, or whatever term you want to use) is not "batching". Otherwise any 32-bit word is a nothing more than a batch of four bytes, and the entire distinction instantly becomes meaningless.
An audio stream can easily be defined as a series of records, where each record is a sample spanning N seconds, probably as provided by the hardware. Similarly, a video frame can also be considered a record. As soon as a record becomes available, it is sent. Thus, streaming.
Optimizing to fully utilize network frames can generally be considered a low level transport optimization, and thus not relevant to the discussion.
They're currently experimenting with things such as actively cooled tiles (which I presume were installed on this ship, since they were on the last two).
I personally think the likely best case is that they'll have to go over the ship and replace some here and there before launching again.