I kinda overdid it with a tape library (40 tapes capacity, LTO-9), but I'm using it for my company's AI model backups. _That_ setup was about $12k.
I had a smaller setup before, with a simple external LTO-5 drive. Used drives are now are about $300, and you can probably find them cheaper. And LTO-5 is the minimum realistic version, it's the first one that supports LTFS and it has reasonable tape capacity.
It's a great service for large caches. For example, we process a lot of imagery that we download from third-party providers. We save a lot of latency by storing the data in a single-AZ S3.
If it dies, we will just have to re-download the data.
That's actually true. AWS is designed to survive one datacenter being offline (which happened more than once, btw). When the first DC in ME was hit, AWS continued working normally, with only a few services experiencing issues.
But it's not designed to survive TWO datacenters going offline, and in a permanent fashion.
One thing about salt domes: they almost by definition are surrounded by very low-permeability dry soils. Because otherwise they would have dissolved long ago!
And a related way to use salt domes is for natural gas storage.
Another related way is to store nuclear waste. The properties (as described in this article, impermeable/self sealing etc.) sound great until the reality that water dissolves salt comes knocking and further confronts you with the reality that salty brine corrodes nuclear waste barrels...
US has some of the world's largest natural gas deposits, and is a major producer of helium, so it makes less sense to have a strategic helium reserve. Even the SPR was created in the aftermath of the last middle east oil crisis, back when the US was a major net importer of oil, and many people have been saying we should scrap the SPR, as no major oil producer has an SPR.
The problem with the SPR is that it is used to manipulate prices, which was why Biden on the one hand cut oil leases and reduced domestic oil production, but then did major SPR drawdowns before the election to hide the realities of these policies. Now Trump is playing the same game, sanctioning oil producers and creating wars in the middle east, but using the SPR to hide the effects of these policies until after the midterm.
In both cases, we'd probably be better off without an SPR, so all of these actions against oil production would be immediately felt at the pump before the election and voters could respond quickly. It's just too tempting to have this tool to manipulate oil prices that incumbents can use before elections.
Huh? The oil price shock in 2022 and resulting SPR drawdown had nothing to do with oil leases. Prices almost doubled worldwide in the span of a week after Russia invaded Ukraine. Look at any chart of petroleum products and it's clearly visible as a huge, almost vertical line.
The explicit purpose of the SPR is to function as a lever to smooth temporary supply shocks. The US increasing oil output by a few percent in either direction wouldn't have made any difference to global disruption of oil markets from a major exporter to Europe starting a war and then getting sanctioned.
Oh yeah. The fucking CSS Zen Garden. It started the trend that led to utter degradation of any usability in modern web interfaces. The idea was to make HTML decoupled from presentation, but the feeble CSS of that time could not express any real layouts.
So very quickly web designers started to just hard-code pixel widths into the CSS, removing any dynamic sizing.
For example, on this very page: https://csszengarden.com/ the two-column layout is done by using two overlapping DIVs with a padding on the left one. You could do 3 columns by using the same trick with left padding.
Want to do four columns? Tough. You'd better redesign your whole HTML for that to work. Or just hardcode the sizes.
Of course, this quickly led to interfaces where buttons have text that is cut off. But with lots and lots of useless whitespace padding around them.
Your frustrations with the state of CSS 2.0 at the time were quite common, and part of what CSS Zen Garden aimed to inspire people to transcend. Now, CSS has evolved to the point where none of these hacks are necessary. You can now write pure, semantic HTML, and pure CSS, and implement full-fidelity designs that work across all modern browsers. That was the whole dream of the CSS Zen Garden, which wasn't fully realized at the time, but now it is.
That's the issue. The CSS pushers did not have any ways of solving the CSS issues.
All that "inspiration" resulted in a loss of scalable interfaces and a switch to hard-coded element dimensions. And this persisted for a LONG time because Web UI designers are, in general, bad and were fine with flashy UI that is finger-breakingly bad.
Heck, it's _still_ a problem because people are by now completely oblivious to that. The art of automatic UI layout has been lost completely.
Umm... this is disingenuous. At the time, most websites were built using tables and were completely non-accessible. One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
No, it's not disingenious. Tables _were_ accessible and easily navigable, including by screen readers. They are also a very logical way of organizing content.
> One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility.
Again, nope. Try a design with 3-4 columns with the old CSS and see how it behaves. The order of elements in the HTML often differs from the visual order, confusing the readers.
It also breaks tab-navigation, even the https://csszengarden.com/ has the "View All Designs" button that is inaccessible.
Then add absolutely-positioned headers and other popular CSS patterns.
It really is not. There's a whole morass with possibly overlapping "on link" networks that nobody can implement correctly on the first try.
Then there's this whole pretend "it's not broadcast but multicast" song-and-dance with ND in IPv6. In IPv4/ARP the separation is clean, and no lower protocol details leak into the IP layer.
Link-local addresses were also meant to be used for LAN-only apps. Except that it quickly turned out that you can't actually use them reliably because some interfaces (like PPP tunnels) do not _have_ MACs.
Morass, mess, broadcast/multicast, etc aside (seems more like complaints of complexity than layering), IPv4+ARP is the textbook example of a layering violation. When you do want to violate, having the L2 info in the L3 packet is still cleaner than L3 info in L2. One is a protocol carrying its own glue in itself, the other is a protocol using different protocols (per L2) to discover the glue the same way it could have itself anyways. It's certainly convenient of course, but that doesn't make it cleaner layering. It also gives a consistent answer for different L2s e.g. cellular links because of this.
Sticking L2 into L3 means that L3 needs the ability to communicate with nodes with as-yet-unknown L2 addresses and that L3 nodes that don’t have an L3 address yet need to be able to transmit L3 packets. Both of these are quite messy, and APR completely avoids these problems.
(I am not, however, defending DHCPv4 - that has some of the same problem.)
ARP does not avoid this problem at all, it broadcasts until enough L2 information is exchanged to unicast (which usually happens to also be the point the L3 information is resolved).
This is the same broadcast-then-unicast process ND uses, except ND can also start as a multicast forward if MLD is supported (naturally falling back to broadcast on the switch if not).
ARP is a protocol that makes perfect sense even when spoken by hosts that only know their own MAC addresses and do not yet know their IPv4 addresses.
IPv6 ND is IPv6 except it has the weird edge case in that it is spoken between hosts that may not know their own IPv6 addresses. So you end up with delights like the “unspecified address) built into IPv6.
If I'm 192.168.129.10 and I want to resolve who 192.168.129.17 is, I make an ARP with the destination as ff:ff:ff:ff:ff:ff. This is a placeholder L2 destination which just means "everyone". I likely need to do something completely different when not on Ethernet (which is surprisingly common when you get beyond PCs on a LAN) and that may or may not involve ARP but we'll stick with ARP on Ethernet for now.
If I'm 2600::10 and I want to resolve who 2600::17 is, the IPv6 destination for the ND packet is set to FF02::1:FF00:17. This is a union of the multicast range with part of the destination address (so the request can almost always only go straight to the 2600::17 node rather than using a placeholder to blast to everyone). If Ethernet is in use, the L2 destination is derived and set to 33:33:FF:00:00:17 by and for the same reasoning. Different addresses will be derived e.g. for 2600::18
If I don't know my address yet (say, for DAD in this example), ARP actually uses a second made up address "0.0.0.0" for the source IP which just means unspecified. In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff. As a bonus, since ND only uses the link local address as the source for ND, DAD for the link local address is the only time the source address can be unknown. DAD for any number of unicast addresses will always have the link local to put as the source, even if they are not in the same subnet in the L2.
> In ND, I do the same to be able to DAD my link local address by saying I'm :: (also all 0s) but at least the destination is still not ff:ff:ff:ff:ff:ff
There is no real difference. All Ethernet packets that have bit 7 set in the first octet are broadcast. A packet to 33:33:FF:00:00:17 will be broadcasted across the LAN.
In practice, ND will flood the network just like ARP unless switches are configured to snoop on higher-level protocols (proxy ARP/ND).
Have you ever asked yourself why there would be 140,737,488,355,328 (half of all) MAC addresses reserved for broadcast if it had no utilities over setting ff:ff:ff:ff:ff:ff? You're correct about fallback replication behavior matching that of broadcast (though that has to do with participating in or snooping IGMP/MLD rather than proxy ARP/ND), I'm just not sure you are considering any implications beyond a single aspect of that one scenario in the above.
That bit is the I/G (individual/group) bit, not the broadcast bit. In switches/routers participating in multicast (IGMP/MLD or snooping of), it is used as the hardware key for the L2 multicast replication lookup. In switches/routers not participating in multicast, unique multicast groups still allow a dedicated MAC entry hardware trap to send the packet to the CPU for processing (VRRP, LLDP, STP, NDP, LACP, and more). Because ARP uses ff:ff:ff:ff:ff:ff you either need to use an ACL on the protocol type in the ingress pipeline or trap all broadcasts to the CPU (both are inefficient in their own ways). The same is true of the host NICs, regardless what the network gear is doing, who can filter all ND requests not to their address(es) by have a match on the ND multicast MACs relevant to the device be processed and then a larger deny matcher for 33:33:FF:xx:xx:xx just drop all others. Also, an ff:ff:ff:ff:ff:ff destination can never be eligible for multicast lookup (even if the switch/router is participating in multicast), so even it's still needed even if a given node might treat it similar to ff:ff:ff:ff:ff:ff.
But yes, if you ignore all of those other things and are in a network without MLD support it'll all fall back to ARP forwarding behavior with just a less generic placeholder address filling the bits. One of the great failings of IPv6 - its approach can be as inefficient as IPv4 in pathological scenarios.
IPv4 is an example of _correct_ layering. The hardware address is a detail that does not leak into upper layers. It's confined purely to the network layer.
In contrast, with IPv6 the whole 64/64 separation is a result of leaking the MAC address into upper protocols. Indeed, MAC was supposed to be a part of the publicly visible IPv6 addresses for hosts!
A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers. It's not just when the addressing bits happen to match between layers, which would be done by the host locally without a separate L2 protocol anyways. Nor was what you're discussing a requirement of IPv6, it was an optional addressing scheme. Nor did it take on as a popular option. Nor does it do anything to explain why IPv4 leaking address resolution down instead of self containing it is supposed to be a correct example.
> That's exactly what's happening in IPv6. The host address leaks information about the underlying hardware into higher-level protocols
I think there is still confusion what "A network layering violation is when a protocol at one layer relies on its information being carried in protocols on other layers" means. As a practical examples:
"Reading a book has a main character 'John' in it and deciding to use that as your name in your speech" is not a layering violation for speech. At no point does anyone need to read to understand your name is John while speaking with you nor does anything break when you change your mind and decide to be called Andsynstd even though it has never been written in a book written in a book.
"You can find my name if you read that book over there" is a layering violation. They have to stop using speech with you, switch to reading the book at a completely different layer of communication, and then suddenly start calling you John in speech even though it was never communicated in speech. If they just say "what's your name" and you say "John" they don't need to get any information from outside the network layer, regardless if the bits in your response also contained your L2 address or not.
In your example, that you read your hardware as one option to come up with your address does not force anyone on the network to use a protocol other than IPv6 to learn your address and talk with you. The litmus test for this is "if you replace Ethernet with a different L2 which can't transport any protocol but L3 protocols on top of it, can you still resolve addresses?" If the answer is no then it's handled externally, if the external handling happens on L2 then it's a layering violation.
> It was a requirement initially.
Not at all. From section 2.4.1 of RFC 1884 in 1995, which introduced the concept of IPv6 addressing architecture you can continue reading past the paragraph mentioning the example of a link-local derived address to see it was never the only example:
Another unicast address format example is where a site or organization requires additional layers of internal hierarchy. In this example the subnet ID is divided into an area ID and a subnet ID. Its format is:
| s bits | n bits | m bits | 128-s-n-m bits |
+----------------------+---------+--------------+-----------------+
| subscriber prefix | area ID | subnet ID | interface ID |
+----------------------+---------+--------------+-----------------+
This technique can be continued to allow a site or organization to add additional layers of internal hierarchy. It may be desirable to use an interface ID smaller than a 48-bit IEEE 802 MAC address to allow more space for the additional layers of internal hierarchy. These could be interface IDs which are administratively created by the site or organization.
> WTF is "leaking down"? The higher protocol levels are supposed to use lower protocol levels.
Hopefully this is already explained in the part about what a layering violation actually is, but the problem is indeed not related to IPv4 riding on top of an L2. Oblivious transport of higher layers is the point of abstracted layers. The problem is ARP, an L2 protocol, is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction. IPv6 corrected this, the neighbor exchange information is always encapsulated in an L3 packet.
"Layering violation" has a pretty clear meaning in CS. It means that a layer needs information from an upper layer for the system to work, or if a lower-level layer internal details are not abstracted properly.
For example, NATs are a layering violation because a router, which is supposed to work on the level of individual packets, needs to understand the details of sessions established in higher protocols (TCP, SIP, FTP, ...) and mangle the packets accordingly.7
The other way around is IPv6. The details of SLAAC that are driven by 64-bit MACs of the Ethernet layer. They make it impossible to use masks larger than 64 bits. The largest installed base of devices (Android) does NOT support DHCP, which is the only non-manual way to configure such addresses.
> The problem is ARP, an L2 protocol
And? What is your point? ARP is not a layering violation, it operates at the correct layer and properly abstracts it. MAC addresses are an internal detail of its functionality, they don't leak into upper layers.
Beep boop :). No, at least not last I checked. I'm just a guy who's day job was developing a NOS which targets both ASICs and a custom software-based forwarding pipelines at one of the main enterprise network vendors. Nowadays I'm PLM for it but kinda miss getting to spend years working with every single bit of these kinds of protocols.
> "Layering violation" has a pretty clear meaning in CS. It means that a layer needs information from an upper layer for the system to work
Maybe you're used to layering in areas of CS outside of networking? E.g. page 476 of TCP IP Illustrated by Fall and Stevens gives an example in the opposite direction than what you just said:
The careful reader will note that this causes a so-called layering violation. That is, the UDP protocol (transport layer) is directly processing bits “owned” by IP (network layer).
That said, you're correct NAT is still also another network layering violation driven by IPv4's limitations.
> The details of SLAAC that are driven by 64-bit MACs of the Ethernet layer.
MACs of the Ethernet layer are 48 bits.
> They make it impossible to use masks larger than 64 bits. The largest installed base of devices (Android) does NOT support DHCP, which is the only non-manual way to configure such addresses.
Android does not use the MAC address derivation mode of SLAAC, it uses randomized addresses mode of SLAAC for privacy. There are several such standardized modes for SLAAC which are not based on the link layer identifier. This should follow because Android's most common IPv6 interface is the cellular radio which does not even have an Ethernet MAC to derive from.
> And? What is your point?
The part you cut off: is not oblivious to the information of the layers above it, such as L3 IP information, breaking the abstraction.
This point will only make or not make sense once we agree what a layering violation in networking is, until then there's not really sense trying to debate it.
Huh? No, the MAC was never a part of the publicly-visible v6 address.
I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
The 64/64-bit split was in fact a result of (then planned) Bluetooth having 64 bit MACs. Moreover, the initial IPv6 RFCs did not have privacy extensions for SLAAC: https://www.rfc-editor.org/info/rfc2464/#section-4
> Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
Broadly it's true that historically there was this idea for ethernet networks at least. It was always optional though. Even in that long obsolete rfc2464 it's described as the way to do SLAAC which was optional even in 1998.
This kind of thing doesn't normally count as violation of layering though. In protocol design its common to leverage identifiers from lower layers for addressing. For example many workings of the internet would be hard to imaging with the rule that you could not use IP addresses and ports in upper level protocols (like DNS, P2P protocols, etc)
The early RFCs were written more informally, so it's hard to say what was optional. However, the consensus was that SLAAC was supposed to be the main way to configure IPv6, along with fully manual configuration.
> In protocol design its common to leverage identifiers from lower layers for addressing.
Yes, that's why my email has the IP address of the mail server. And why my WhatsUp contains the IMEI of my phone.
Technically, there's no broadcast in IPv6, so the host is supposed to join the local multicast group and do the neighbor discovery flow to find the "on link" address. And it's not guaranteed that the network is "symmetric".
Technically, this is also true for IPv4. You can have a proxy-ARP host impersonating the sender, but since it had never been fully specced, nobody cares about this scenario.
It's a perfectly fine protocol, with a rigid schema and mature code generation support for all relevant languages. It's not the sexiest protocol, but it gets the job done.
> mature code generation support for all relevant languages.
Heh, "relevant languages" is kind of an interesting term there. If the relevant language is Java then sure, it's fine.
Some popular modern languages (ie Go) don't have good SOAP support (yet). At least not to the point of being able to point them at WSDL/XSD specs and have everything auto-generated. :(
That seems like a Go problem. I don't exactly love SOAP and WSDL, but it was the default choice for Java and .Net 10 - 15 years ago in enterprise applications. Given the complexity, rewriting it a few years late, just to switch from a perfectly functional SOAP API to REST makes no sense and would mean that you either run two stack, or force every integrator to rewrite their software.
That's just no how the real world works. When this was launched Go probably wasn't a relevant language, Rust probably barely existed and the whole thing was designed for a corporate setting, where Java and .Net are the standards. All those who are asking "Why SOAP?" or suggests replacing it seems rather naive about how most corporate software is sold, designed, built and maintained, as well as expected lifetimes of solutions.
Eg Python is barely trudging along with random forks of a library that stopped being supported 10 years ago, each fork only getting maintained for about a year at a time.
I really think outside of Java and c#, soap is totally dead.
I think that‘s a matter of days and few hundred dollars in tokens to port it to Go if you really need it.
Porting is where AI can do a really good job with the right instructions.
It's more than just a few days of effort though. Sme of the members of my team at work have been working on adding SOAP 1.1 support. It's a significant amount of time and effort though.
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
> Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
Oh yes, part of the gigantic OASIS UBL (ISO/IEC 19845) and EN 16931 (CEN/TC 434). If young devs today think AI likes to build massive overengineered jargon-filled monstrosities, they should see what they learned it from. Never mind how to get a paycheck, we'll worry about that later, freeing humans from working on this stuff is a humanitarian obligation.
IBM has always been better than Oracle. It makes giant expensive software and hardware that require arcane knowledge to keep them running. But they also run reliably once you insert enough money.
Oracle's stuff JustDoesn'tWork(tm) once you move past its core database offering. And even that (see: RAC) is sometimes problematic.
This is super-dumb. The same thing is happening with Russian banks.
Their answer? They're now asking users to install root certs from the Russian ministry of communications. So it can now MITM all the encrypted traffic in Russia.
On the other hand, LTO-5 drives are now pretty affordable. And each tape cartridge holds around 2Tb of data for about $20.
reply