If it's legal, you can do it. Figuring out whether it's legal is a giant error-prone jurisdiction-dependent pain in the ass.
Even if it were illegal, you could have done it by releasing anonymously (on edit, and reworking the code to remove Fable's fingerprints)... if you hadn't first blown it by publicly posted a traceable question.
Yes as a teenager I made many mistakes, not least of them being making a Gmail account. I even used it to sign up for a few services. I do have a bit of a wild side so sometimes I log in to check it.
> Every closed source software has the potential to centralize and lock you out of it.
... and you can write your own alternative software.
But you can't provide your own 2TB GPU to help you (or to run it, if that's what it needs). So if They(TM) don't like what you're doing, They(TM) can put you at a vast disadvantage compared to everybody else.
> But you can't provide your own 2TB GPU to help you (or to run it, if that's what it needs).
Worst case scenario: high performance chips will be controlled like drugs or firearms (outside US). Like, requiring a license to own, being allowed to use only for specific "safe" purposes, possibly having to submit some kind of telemetry to prove that you are not doing anything "unsafe".
Except, unlike drugs and firearms this control might actually work, because you can't cook chips in an underground lab (unlike drugs) and there are no gazillions of chips in circulation some of which will inevitably slip through the cracks (unlike firearms). I mean, of course there are chips in circulation, but if such control ever will be implemented, you can allow older chips and only control those that are released after passing the law. Eventually, uncontrolled chips will become hopelessly obsolete.
Counting the cost of creating the company so you can actually deal directly with a NIC?
Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
>Counting the cost of creating the company so you can actually deal directly with a NIC?
No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)
>Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.
> I argue that all servers should have an IP(v4) adress, you argue that every client device should.
In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance.
My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its also a "server" when I'm connecting to its file shares. Its also a "server" when I'm wanting to stream games from it. A game console is sometimes a "client" when its downloading games and updates, its also sometimes a "server" when I play games online and do matchmaking. My phone is a "client" when its talking to the messaging app servers, it is also a "peer" when I make a phone call to my friend.
Thinking that things are only ever "clients" or only ever "servers" is an overly simplistic view of the world. Devices aren't purely "servers" or "clients", applications/services are what make such a distinction, and even then that can change depending on the context.
I agree that there is no technical difference in the original ipv4 standard.
There is one in the og tcp standard though. Server, listening, ports are well known, and they uhh listen. Might be semantical, but it's in the spec. Listening port is dedicated to an application type.
Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must retain that property. See? They are different in technical nature.
That's without even getting into empirical protocol semantics. Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections. Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.
> Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must retain that property. See? They are different in technical nature.
No. Both servers and clients can have no public ipv4
> Server, listening, ports are well known, and they uhh listen
Sure, but that's the application not the device. A device can have outbound connections and can be listening.
> clients can have no dedicated ipv4, but servers must retain that property. See?
My desktop at home has no public dedicated IPv4 (technically neither does my router, it's DHCP and subject to change), and yet still has listening ports.
If I've got httpd running on multiple things on my LAN which get IP addresses from DHCP, and I've got a reverse proxy that's getting NAT'd traffic from the router and proxying those requests, what is the "server" in this setup to you? These devices don't necessarily have dedicated RFC1918 IPv4 addresses, they're all just DHCP and register those IP addresses in the DNS which is referenced by the proxy. They'll change constantly for this example. (Note: this is extremely common in containerized or autoscaling deployments, not entirely a hypothetical!)
> Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections
Sure it does. It's got dozens of ports permanently opened. That's my point. It's not like I have to go to the server store and buy a server to have ports open. I just launch a process and make a change to my device firewall, and now I'm a "server". The same device I'm using as a client to talk to you right now. Incredible! I can even use the same application, like a videogame, to be both a client and a server at the same time! I can start a match, join it at the same time, and allow outside players come join, and that might all technically be in the same executable!
> Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.
The router is just routing packets. It is not opening a listening port. It gets a packet delivered, it applies a set of rules to it, and passes it out an interface. If you think a router has to be "listening" on a specific port to receive that packet, you're misunderstanding what a router is doing. Sometimes you might even NAT without taking into account a port or a protocol at all!
I would say the lack of deploying service locator records in DNS was also a major contributor. We have trillions of ports/ip combinations available and we use waste bits by always using 443.
I'm sorry, but a multi-kilogram (at a guess), five-figure-priced (at a conservative guess) device with kilometer-scale error (per their actual press release) is not a substitute for a GPS.
And you probably can't improve on many of those specs no matter how much "inventing" you do. There's just not that much information in magnetic fields, especially if you don't spend an infeasible amount of money on keeping maps up to date. You're probably jammable, too.
The same applies to the gravitational hacks, and the mapping issue applies even to visual navigation.
Those guesses, by the way, are because not only is AQNav's "data sheet" worthless fluff, but they seem to be allergic to letting anybody even see a picture of the product. Which makes me doubt that they actually have what a normal person would think of as a "product" to begin with.
Datasheets that look like that are a pretty strong indicator you're dealing with something that is giga export controlled, not as in "can only go to some countries, you have to declare it and theres a LOT of paperwork", more "attempting to, or even making plans about trying to leave the country with one is a pile of federal crimes"
Virtually anything navigational that cannot be easily or reliably jammed falls into this category far before meeting any of the accuracy/drift requirements.
... because people (by which I mean software vendors who should have known better) irresponsibly failed to create secure systems for those average users to use. A whole lot of which came to be justified by "it'll be behind a firewall" thinking.
Did you forget dialup was a thing? No one created anything for home users thinking it would be behind some firewall because as said Windows didn't ship with one, and because the dominant way of customers getting online was dialup, giving a public IP to every user.
Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.
> "No one wanting to bother with port forwarding" is largely a matter of shitty UX on the home gateway side and laziness on the side of the operator. Same with UPnP.
If you try to use those port forwarding hacks, you force every single piece of software to deal with the fact that the IP address it sees for itself is not the IP address its peer sees for it. And you force every single protocol design to allow for that possibility. Add in UPNP, and now you have to implement a whole extra (badly designed) protocol in parallel with the actual application.
It's not trivial to even discover the address your peer is seeing; even now there's a huge diversity of nasty unreliable hacks for doing it.
HTTP isn't the world. In fact, HTTP becoming "the world" was another part of the problem.
I was alive and don't think I've forgotten. What distinguished large from small users was the width of the pipe. Address space charging was never important as a revenue driver. There were some attempts to charge for address space to keep people from getting huge blocks they didn't use. The long term solution for that was, of course, supposed to be IPv6.
If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.
Even if it were illegal, you could have done it by releasing anonymously (on edit, and reworking the code to remove Fable's fingerprints)... if you hadn't first blown it by publicly posted a traceable question.
reply