I think it's more a consequence of pushing for the biggest valuation/IPO. Rumoured profits on inference are north of 70%.
Taking SpaceX as an example, they have increased prices across all their consumer products over the past six months. But they definitely aren't short on money with Alphabet and Anthropic combined paying them over $2 billion per month.
Microsoft/GitHub lost out here as they were just repacking other people's products.
Inference can only happen after having invested in training and datacenter construction. Arguing about "inference profitability" sounds a lot to me like ignoring large cost centers of these comanies.
You can make some educated guesses and find out some limits on inferencing cost by looking at 3rd party providers on platforms like openrouter. You can get some median cost /tok for a given model size. Then make some educated guesses on SotA model sizes, and you can get an estimate on pure cost of serving a model. Error bars and all that, of course. But still a range, with some limits.
No, you can't really make educated guesses unless people start opening their books. Especially in an industry where the vast majority of firms make up valuations out of thin air and not based on any reproducible insights.
Opening their books would let you know things like profitability. I'm talking about cost per token, model development and human costs being irrelevant.
Yeah take the gpu rental cost, what it can run, how many tokens per second come out and see the true rate per token. Plus the margin on harness special sauce
How is spacex not short on money when no one will pay them to use their models and they lose money every quarter? Sure they’re now transitioning to a data center provider away from actually being an AI company because they’re losing less money that way but it doesn’t sound like a strategic success
The github example is also a bit of an outlier because they made a recent change to their pricing so that's why its such a drastic jump.
Also I mean prices in generally for all things are based on underlying factors, that doesn't make them arbitary (i.e. github executives using a random number generator for token pricing would be arbitary)
UUIDv7 and sequential integers are quite similar. Sequential integers disclose count and neighboring IDs while UUIDv7 discloses timestamp. Either can be a security issue in certain cases.
So, UUIDv4 as a PK on a clustered index can be perfectly feasible for cases where you want to avoid disclosing stuff and row insertion performance isn’t that important.
It’s not exclusively an IPv6 feature: RFC 3927 defines link-local IPv4 addresses, to be assigned randomly from 169.254.0.0/16 after a bit of ceremony to detect collisions.
Ideally, you’d be able to connect a PC and a printer with an Ethernet cable, they would both (having failed to find a better alternative) allocate a link-local address for themselves, and then the PC would use DNS-SD over mDNS to discover the printer and show it to you. Similar story with PCs exporting their media files over the network, a—say—set-top box, and a switch they’re all plugged into.
And for some combinations of parts this actually works. It’s just that the functionality is not always well-exposed by the OS, that a switch + DHCP server in a box (in practice, a consumer router) can work just as well with no configuration as an unmanaged switch can, and that people are not that interested in local-only wired networks anymore.
There’s also the “having failed to find a better alternative” part: unlike with IPv6, the RFC does not endorse always assigning a link-local address as the second one next to a static or DHCP-provided one, I’m guessing for software compatibility. Thus you really only see 169.254.* in your interface configuration when DHCP is borked, and it’s kind of useless in that case.
The IPv6 feature isn’t link-local addresses, it’s being able to specify the interface to bind to as part of the address specification. This lets you demand that your IPv6-based tool use your wired Ethernet connection, for example.
> The IPv6 feature isn’t link-local addresses, it’s being able to specify the interface to bind to as part of the address specification. This lets you demand that your IPv6-based tool use your wired Ethernet connection, for example.
I don’t think a design goal of IPv6 was to enable users to demand which link the kernel uses or open up some rich new world of link local ip services. I think it’s more like “because IPv6 hosts assign everything an address all at once, there’s a new problem when two interfaces use the same link local addresses since we can’t guarantee uniqueness so we have to invent this stupid zone_id convention to work around poor protocol design and implementation”. Design goals are different than constraints.
Have hosts put a guid in its LL address and print that on the sticker next to the mac address… idk. Actually it’d be nice if we only did link-exclusive things at the link layer, eh?
Yes, but the question is, "what if an address in this range is assigned to _two_ interfaces at the same time?" Now your local routing information base cannot distinguish which interface to use when trying to reach other hosts in that same network. So, it's fair to say, it's not a feature even available in IPv4.
The second difference is IPv6 is almost always going to have link local addresses assigned and machines with multiple network interfaces are the norm rather than the exception.
I literally had to interrogate an LLM to explain what this was about, because to me, indeed, when I see 169.254 I think "Ah, someone unplugged something critical and the network is now completely down." I didn't even know that in ipv6 land there are any reasons to use link-local addresses for anything. I mean, there still basically isn't a reason for 99.99% of people, I think. But it's interesting.
I also didn't realize that part of the idea behind these LL things was one of the rounds of wishful networking ideas of the 90s or 2000s, kind of a cousin of UPnP and mDNS in that way (in increasing order of eventual usefulness).
Considered completely in a vacuum, especially ignoring the WAN, I can see how it seemed silly that if you plugged three computers and a printer into a switch, rolling random IP addresses like this could have allowed things to be discoverable and to function locally (I thought mDNS or "Bonjour"/"Rendezvous" as Apple called it came much later, but I know my PCs could "see" each other with NetBIOS or whatever long before mDNS was invented).
Link-local addresses (LLAs) are needed in IPv6 because IPv6 doesn't have broadcast. IPv6 uses multicast instead.
Broadcasts go to all IPv4 addresses in the subnet, multicasts only go to those who subscribed to a multicast group. To subscribe to a IPv6 multicast group you need an IPv6 address. So all IPv6 interfaces will have at least one LLA self-generated.
One thing that IPv6 uses multicast heavily for is NDP, which is the IPv6 version of ARP. This is how IP addresses on your LAN/WLAN are converted to MAC addresses which is required info for the NIC in your node to talk to another node on your Ethernet LAN/WLAN.
End users don't typically have to use LLAs directly but you can use them if you want to 100% ensure things won't leave your LAN as routers don't forward LLAs.
mDNS on link-locals is what makes the "plug computers and printers into switch" case work. It would have been NetBIOS originally but mDNS is how it's done today.
I wonder how many readers realized your joke here. For the ones who didn't, the 4-byte "magic number" that identifies Java .class files, in hex, spell "CAFEBABE".
It's also just sort of generally used as easily spotted value in a hex editor. similar to DEADBEEF, ABADBABE, CAFED00D, and probably a bunch more variations on the concept. CAFEBABE seems especially prolific, getting used for -- among other things -- poison value for memory pools in plan9 and MACH-O universal object files magic number[0]
URL parsers don't break, the amount of code to change is not that big, and many of the user-space applications can keep working with no changes at all, as long as they use high-level network libraries.
If you really hate this for some reason, use some other characters. How about underscores (_) for example? Those are not valid in DNS, so there is no chance of confusion.
Choosing colon when URLs were already using it is either very stupid or very mean.
There is the .arpa domain used for reverse lookups. ipv6.arpa is already used for that. But combining the ipv6-literal from Microsoft, gives ipv6-literal.arpa.
I used to play the demo of Test Drive III. It only had one map I believe. But I loved that it was a sandbox, so you could drive anywhere. I specifically remember following along the railroad. It was way ahead of its time back then.
I remember the controversy over the original Postal, and then there were eventually 3 more sequels in that franchise. The culture resists at first and eventually loses the battle.
Time for a modernized port true to the original! I also liked the TrackMania series but I wish there was something reduced to the amazing essence of Stunts.
There was a FidoNet clone in Turkey called HitNet (short for “Hi Türkiye Net”). Its node addresses were like “8:103/119”.
İ developed a Netmail server for Hitnet called HitBase in 1995 or so. It allowed people to discover others around their city to meet. Possibly the earliest thing that resembles Facebook. Similarly, it was a privacy nightmare too, luckily short-lived.
HitNet introduced me to great people some of whom I still see today. It was such a tight-knit friendly community.
The advent of Internet killed it but some communities are still active on other platforms.
Forgot to add, I also developed a BlueWave-compatible offline-reader called Wolverine that worked for all Fido-style networks: https://github.com/ssg/wolverine
Such drastic changes tell me that pricing of tokens is arbitrary, and AI business is running out of money fast.
reply