>Cutler found what he terms "the worst code he has ever seen," some IME code developed in Japan. He states that the code had no regard for bugs and that it got to a point where they couldn't fix some of the overflow plugs.
In the very same article he said:
>However, progress on this project halted as Windows XP's security had gone from bad to worse. Cutler states that his team alone fixed over 5,000 bugs while turning over some of the system's code.
His team fixed over 5000 mostly security bugs in Windows XP, and he still thinks it's still better than "some IME code developed in Japan". The mind boggles.
I think it’s not so much that the code doesn’t do what it’s supposed to. It’s that it’s an absolutely impenetrable mess. You’d never know if there were bugs unless your customer (or QA team) runs into them.
I've been reading his drivels (in a good way) since the 90s. God speed "Mad" Mike Magee.
Supposingly he was friend with the current CEO of Intel, Pat Gelsinger. In the 90s during a meeting with Intel staff, Magee asked a very uncomfortable question and Gelsinger, then an engineer at Intel, kicked him under the table to stop him.
Since then whenever Mike reported news on Gelsinger he would write his name as "Kicking" Pat Gelsinger.
Magee also started Charlie Demerjian's career by hiring him as a freelancer at The Inquirer. Demerjian then made a name for himself by being a very accurate pain in the ass for Intel and Nvidia for years to come.
I remember meeting Charlie in 2009 at Nvidias GPU conference in downtown San Jose when I was working for NV at the time. It was me, Jensen and Charlie. I remember Jensen putting his arm around Charlie and pointing at him and making some jokes about what a pain in the ass he was. Thats all I remember, unfortunately. I quit drinking since then. At the time, Charlie was the celebrity not Jensen. I grew up reading the inquirer and saw Charlie's name attached to everything I read. Mike Magee created something that launched my entire career trajectory and gave a voice to a subject that I was so passionate about with no one around me to share it with. RIP
Most RFID card systems in the world uses MIFARE Classic due to its cost and long history.
MIFARE (not just the Classic family) have a UID (32 bits) and x blocks of encrypted data (12 for Classic). Each block is protected by a A key and a B key.
The earliest card system only uses UID for authentication ie. if the card says the right UID the card passes authentication.
Obviously, anyone can forge a card with said UID, so the latter system start to use the 12 encrypted fields for authentication. The card reader would challenge the card to encrypt the nonce plus stored identification. Only cards with the correct key can respond with the correct encrypted data + nonce.
The authentication uses symmetric encryption. Depending on how the system is setup, A key is used for Read only, Read Write, or A is used for read and B is used for write, or both A/B is need for read write.
The original Mifare Classic uses a proprietary crypto crypto-1. Due to various reasons (eg. weak PRNG, collisions, etc.) , it can be trivial to crack a traditional Mifare Classic key. However there are harden keys that still could not be cracked due to various countermeasures.
The paper seems to found a hardcoded A/B key A396EFA4E24F for a particular brand of RFID cards (I just skimped the paper and its been years since I worked on RFID. I might be wrong on the detail).
> The paper seems to found a hardcoded A/B key A396EFA4E24F for a particular brand of RFID cards (I just skimped the paper and its been years since I worked on RFID. I might be wrong on the detail).
Actually, if I understood the paper well, the same key worked also on older, non-Chinese cards like those produced by NXP. Why, that's a big question.
Would you happen to know of a good reference for this? I have a Proxmark and I'd like to learn how the encryption works so I can play around with (and maybe clone) some of my cards.
These systems usually do mutual authentication, and that's as much a side effect of the cryptographic primitives used as it is an intentional feature:
They're often using symmetric cryptography (even ECC is orders of magnitude more complex than a simple block cipher), and you get mutual authentication "for free" that way, in exchange for having to guard the keys on both the card and the reader to prevent a total compromise.
1. The badge manufacturing issue and subsequent non-payment due to contract dispute.
2. The firmware author (not hired by the manufacturer) put in unauthorized 'easter egg' code that asks for money via crypto.
I am not familiar with 1 so I can't comment on a contract dispute.
But 2 is definitely over the line, and this is coming from me who is supportive of some usage of cryptocurrency. You don't put in unexpected monetization mechanisms into your volunteer work, without asking the charity organization for permission. Asking for money secretly is way different than putting in a harmless Easter egg. At that point, it's not a harmless easter egg anymore.
Maybe the money is for the manufacturer. In that case, do what a normal person would do and raise the issue on a social channel (eg. Twitter, Thread, blog).
Yes, it was for the manufacturer, not for the firmware author himself.
I agree that he shouldn't have put in the donation solicitation, but I think DEFCON's response to kick him out of his talk was an overreaction. Especially considering what prompted the easter egg was DEFCON removing the Entropic's badge credit from the badge case that they were promised. Even if DEFCON's statement about the manufacturing/cost issues with the badge (your point 1) was entirely true, the final badge that ended up in attendees' hands was still almost completely Entropic's and Dmitry's work, and they deserve credit for putting together something of that complexity in such a short time frame.
No one is coming out of this looking perfectly rosy, regardless of the truth behind things. The donation link was over the line, but DEFCON's change to the badge case was completely unethical, and disinviting Dmitry from the badge talk over an inappropriate easter egg was a dirty thing to do.
>low-level exploitation is rarely needed in cybersecurity
Sadly that's true. I am transferring from a low level pentester to web app security engineer. That's where all the jobs are. People don't really care how much you know about low level.
Done forget to have a secondary identifier to further divide the seat. I recommend using a short to represent the 65536 possible slices a seat can split.
Then on the ticket, there would be an extension section that tells you the alias of the person that is about to board. We can call it SNI or Sitter Name Indicator. Another section could be an indicator if the rider is alive when boarding. We can call the extension a heartbeat extension.
The funny thing is that IPv6 is used more by general public more than professionals. Public doesn't notice that their mobile network is IPv6, or that there home internet also supports it. It is the professionals that are dragging feet upgrading the business networks.
More people access Google with IPv6 on weekends, currently 46%, than on weekdays, 43%. Presumably because mobile and home networks are more likely to be IPv6 than offices.
No, IPv6 is the underlying technology behind the general consumers' internet connections, but the general public is not using IPv6. The general public has no idea what IPv6 is.
I.e. IPv6 is used by the general public, but the general public is not using IPv6.
By that same token the general public is also not using IPv4. The general public doesn't care, so long as TikTok and Facebook appear on their mobile devices.
When I drive my work van I use a throttle body, when I drive my car I use a carburettor. From my point of view as a user, I'm just driving a vehicle. The point is that users see a holistic system and neither know nor care about the underlying implementation details.
We could also have bumped 255.255.255.255 to 999.999.999.999 = 1 trillion IP addresses, easy-to-remember and backward compatibility with legacy devices.
Modern clients and servers get IP addresses in these new whole IP ranges and can communicate together.
Relatively easy to adapt the code of modern software also since it's about removing a restriction from a client-perspective.
Load-balancers and legacy clients use IP addresses from the old pool.
If you have Windows XP you can communicate only to legacy IPv4 (in practice only loadbalancers from Cloudflare, GCP, AWS and co) and your other legacy stuff.
Others happily communicate together.
But no, we got this wonderful IPv6.
Sad because it was really doable, theoretical maximum below 512 GB of memory for routers to store the whole routing table, it's manageable, versus the 2.176×10^22 exabytes (!) of IPv6.
I'm guessing everyone downvotes you for the very strange implication that most software stores IP addresses in ASCII. All networking APIs I'm aware of expect IPv4 addresses as a DWORD.
This is the point, instead of rewriting a full stack, I would rather change the prototype of these APIs.
To store 999.999.999.999, then you are totally fine with a 64-bits INT (QWORD), and there is no struggle to backward-compatibility store a 32-bits INT (DWORD) into it.
It's more of a matter of doing #ifdef IPV4_EXTENDED #define DWORD QWORD #endif
and add an extra IP field inside the IP header packet itself that says, "this is the IPV4_EXTENDED DESTINATION 5-bytes IP", and the previous field is marked a legacy/deprecated.
In fact, it's quite convenient, since we are all INT64, sockaddr_in would largely fit in an INT64 for both IP itself and the other elements that are in the struct.
5 bytes for the sin_addr field is enough to store until 999.999.999.999.
Gives you 3 bytes to store the port etc.
The networking APIs guys could be drinking cocktails at the bar by now, if they would change these types.
There is backward compatibility and smaller effort for a great impact, and this is beautiful.
It's actually beneficial for the majority of developers.
From the developer of Windows, to the developer of Age of Empires, to the developer of a CRUD app on the web (who stores IP addresses as a string or as an int), they wouldn't see too much struggle to port to int64.
Less than having to build a full new IPv6 experience.
In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted.
time() had a similar situation.
We migrated by adding new bytes, we didn't redefine the concept of time.
From a developer-experience, "link to the latest version of the network library, oh btw, connect() accepts an int64" and remove the UI restriction of 255.
It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
So you need to send a message from your host 5.6.7.8 to one of these newly enabled hosts 500.600.700.800. You update the software on your host, and your target's ISP is updated, and your target updates, and we'll even hand wave and assume your ISP is updated despite apparently having enough legacy addresses to allocate you one.
The message goes out to your ISP router, who then sends it to their upstream ISP, who looks at the IP message, doesn't understand whatever header you've shoved the extended address in, and discards it. Then what's in your standard, backwards compatible 32 bit field? The start of the address? Does your packet go to some other random host on the internet? A placeholder address like all 0s? Does your message get discarded?
How do you convince that middleman to update their hardware? They have no benefit from it? This is the situation IPv6 was in for decades until their literally were not enough IPv4 addresses which finally lit a fire under companies to start enabling it.
(I'm not pushing this idea to the max, I mean, now IPv6 is here so we'll just go with it, but this is for the mental and engineering exercise).
To answer your question, in my model, the legacy IPv4 field contains the IP addresses of "IPv4 to IPv4 Extended bridges".
Let's imagine you want to connect to [example.com]:
Clients who speak IPv4 Extended and their ISP is compatible, get the IPv4 Extended answer:
425.223.231.123 A+ example.com
and directly to it
Clients who speak IPv4 Extended but don't have an IPv4 Extended compatible ISP, add that extra IPv4 Extended header and speak to the bridges.
425.223.231.123 A+ example.com
34.23.12.2 BR example.com (the bridge)
Clients who speak IPv4 only but don't speak IPv4 Extended don't have to think about IPv4 Extended at all, since they will go through the usual layer-7 (typically HTTP) reverse-proxy, or a routing based on rules (ip/port pair).
Cloudflare does search large scale reverse proxies, it works fine in practice.
If someone has an incentive to run such bridges or reverse proxies solution, first it's yourself, to save your preciouses IPv4.
To the end user the promise is "you will connect faster to the internet if you are in native IPv4 Extended (because you skip these intermediate bridges)"
We actually have a nice mechanism that we could reuse for knowing which bridges to use, it's reverse DNS lookup.
> In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted.
A lot of networking gear is far closer to an ASIC than a general-purpose CPU, so you can't "just change it to int64". They were built to process 32-bit addresses, and are unlikely to be able to swap to 64-bit without enormous performance penalties.
E.g. routing tables would balloon in size, which in practice means that you can store far fewer routes. Ignoring changes in the size of the netmask, it's 4x the size to store 64-bit address pairs, so your route tables are a quarter the size they used to be.
The hardware refresh requirements are a big part of the reason why IPv6 rollout is so slow, and your proposal doesn't avoid that. Getting the software side of things to play nice has always been the easy part of this, even in IPv6.
> It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
In IPv6 land, you just encapsulate IPv4 in IPv6 [1]. It's a lot cleaner than jankily trying to override instructions, especially when the relevant code may run on your NIC rather than your CPU and require kernel firmware patches (or, god forbid, custom NIC firmware) to implement.
and what about the protocol bytes that go over the wire - you know, the most important and hardest to change part?
There've been several proposals to make "IPv4 but bigger addresses". All of them are just as hard to deploy as IPv6. You still need to upgrade all your routers and you still need to run two parallel networks.
If it's going in the same spot in the packet header as the current IPv4 address, how do you make sure that the 20-30 routers owned by 3 different companies that are likely to be between your computer and the destination computer exhibit a behavior that is consistent with moving packet closer to the destination?
(If they don't, you've just made a version of IPv6 that is worse-- it's missing the last 30 years of IPv6 implementation.)
It's written above, bridge destination address in the "legacy" IPv4 destination header, and that bridge can be figured out by looking up the reverse dns entries on a IPv4 Extended IP, until the user is natively using an IPv4 Extended network.
This brings the packet closer to the destination.
The new address goes into the Options field, you can store lot of data there (somewhere up-to-60 bytes, and we need 1 or 2 byte actually).
Reminder: The goal is to add one-byte to have more IP addresses, not rewrite the whole internet.
Here it looks like the guys wanted to fix that IP allocation problem, and then they went all-in, and decided to rewrite everything at the same time.
It's ok, and even a good idea in theory, but network administrators don't like to be pressured "in emergency" into upgrading to this solution.
The practice shows that people rather prefer doing NAT than IPv6.
Do your devices behind the router get IPv6 addresses, or just the router itself?
I wouldn't be super surprised to see routers getting IPv6 addresses and doing a 6in4 NAT, so devices behind the router get IPv4 addresses.
I would be surprised and impressed if your devices were actually getting public IPv6 addresses.
IPv6 can be kind of unwieldy, but the bigger issue to me is that old and/or very cheap clients (like bargain-bin AliExpress IoT stuff) may not support IPv6 at all.
I believe you can run DHCP for both and let the client pick one, but then you're into running dual-stack routers, and I would be very surprised if ISPs had any interest in supporting them for home use.
I may well be wrong, though. I haven't looked into it in a few years, because my ISP doesn't support it.
edit: Okay I thought it did but apparently my router doesn't assign publically routable IPv6 addresses by default. I found a setting that would enable this though. Gonna leave it off for security reasons, but it's just a toggle, so still seems pretty easy. Also my local interface apparently has an (unrouted) ip in the same subnet as my router's public address, and I'm not sure how it got it.
Every device on my LAN that responds to Bonjour on `.local` uses link-local IPv6 without me having had to do any configuration or put any thought into it whatsoever. ¯\_(ツ)_/¯
EDIT - Oh, you’re talking about public IPv6… similarly, my router (a TP-Link Archer 1200) gets assigned a prefix by my ISP, which it then auto-assigns inside devices IPs from, again without any explicit configuration or intervention on my part. Super easy.
Do you understand on what basis? Do you know enough to assign addresses in a way that you, not your router, wants?
Can you ssh/other forms of remote into any machine that accepts ssh on your local network using only ipv6?
Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
Speaking of which, since the ISP decides on the addresses behind your NAT, can two separate ipv6 internet connections even exist on a local network?
This is all easily doable with ipv4 in like two afternoons without setting up anything beyond perhaps a dhcp server and some firewall rules. How many additional services do you need to do that with ipv6? And how enterprisey are they?
Do not "ssh/other forms of remote" using ip addresses. Use domain names or local domain. It is easier to remember, is more secure (if configured in DNS), and less prone to errors.
> Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Yes. Use domain names in configuration files. It more robust, easier to read, and is better protected against network changes on the local network.
I have been part of multiple ISP changes and searching through configuration files for ISP specific IP address ranges is never fun. It wastes time and is prone to errors. In enterprise settings domain names rarely changes and even when they do, the old primary name are usually retained for backward compatibility. An ISP can get replaced fairly quickly if an alternative is cheaper or provide a better service.
> Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
Are you talking about BGP? BGP is a fairly complex protocol and uses some archaic configuration syntax, but even so there are generally no differences between ipv4 and ipv6. It is the same pain making sure both ipv4 and ipv6 switch between the two routes correctly.
I have absolutely no problem remembering the last byte of any machine on my network. Because that's all it takes with ipv4 on a sorta complex home network, no need for extra services.
> Are you talking about BGP?
No, with ipv4 i can just change the default route :)
Everything is NATed behind the two routers so changing the default route changes which connection that machine uses. You're thinking enterprise, and then ipv6 becomes ... fine. I just have a hack that works fine for me.
> Do you know enough to assign addresses in a way that you, not your router, wants?
If I want to manually assign addresses it's still pretty simple, but in the end I normally just don't care. I don't want to know what IP my printer is, I just want to reach it. Which isn't a challenge at all. Even for things at my home that are IPv4 only they're practically all DHCP. Because there's little reason to ever really care about something's address.
> Can you ssh/other forms of remote into any machine that accepts ssh on your local network using only ipv6?
I have no problems reaching any host on any of my networks even if they're running only IPv6. It's nice too because I can trivially reach any port I want globally as well with a basic firewall change. Even better I can have one host have many IP addresses with different services bound to each address if I want.
> Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Why do any port redirection at all? Just set the firewall rule and things can hit it. And yeah, they can keep constant addresses. They can have dozens, hundreds of static host addresses if I want.
> Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
If that's something you're really wanting, Network Prefix Translation can be done pretty easily. But the vast majority of home users aren't using dual WAN anyways.
> This is all easily doable with ipv4 in like two afternoons
Sounds like your setup with IPv4 took more work than mine with IPv6, as mine only took me an hour or so while yours took multiple days.
> as mine only took me an hour or so while yours took multiple days.
Yeah, because the first time I had no idea what I was doing, except vague feelings about ipv4 works. Did you factor in your pre existing ipv6 knowledge when you counted just an hour?
> Network Prefix Translation can be done pretty easily.
What's "easily"? How many services do I need to setup? Some other helpful HNer tried to explain to me once and the list was like 2 or 3 daemons in addition to dhcp, firewall etc.
Your standard was "It's unusable on your fucking home network."
I've set up and managed IPv6 at work before, yes. I don't know if I'd call them "complex" networks though. Either way I set it up at home several years before. And I had been running IPv6 at home before I even bothered setting it up in a way I wanted, as my ISP's box previously had a decently competent SLAAC and IPv6 firewall setup in their CPE router. So that took me 0 minutes of time past plugging it in.
As for this disdain of running such complicated systems like "DNS", so many things support mDNS these days and plenty of home routers will automatically update their local DNS with DHCP entries. I didn't have to manually configure a DNS entry for my printer, I just gave it the hostname "brother" when I first set it up and now when I need to add it, I just do "brother" on a new computer and boom it finds it wherever it is. If I want to check the toner level, I open a browser and go to http://brother and its there. And even though I've radically changed my networking setups over the years, all my configurations pointing to "brother" still just work.
But hey just complain about how it's just impossible and takes so much work instead of actually learning new things.
From the sibling comment:
> No, with ipv4 i can just change the default route :)
Are you suggesting you're running around and changing the default route on all the devices on your network when a gateway goes down? What a nightmare. Just have your router have multiple WAN connections and have it do the failover for you.
> I have absolutely no problem remembering the last byte of any machine on my network
If you want, you can do the same with IPv6. You could set your stuff to have your IP addresses be fd12:3456::1, then fd12:3456::2, then fd12:3456::3, then fd12:3456::4, then fd12:3456::5, etc. Remembering 123456 as your home ULA prefix isn't too challenging, is it? You can then set up an NPT rule like the one above on your router to translate this prefix fd12:3456::/64 with whatever your public prefix is from your ISP. Most wouldn't do this though, as its essentially the Fisher Price of networking designs.
> As for this disdain of running such complicated systems like "DNS"
Disdain? I run a few bind instances for my own domains. On rented servers where they belong. I'm just opposed to having one required for my local network.
"NPt makes perfect sense for SOHO IPv6 Multi-WAN deployments." Wait, they agree with me. That there are SOHO IPv6 Multi-WAN deployments. Who would have thought?
> running around and changing the default route on all the devices on your network when a gateway goes down? What a nightmare. Just have your router have multiple WAN connections and have it do the failover for you.
It used to be that but I don't think any of my internets has failed since like 2010... mostly keeping them out of inertia. So I've never felt the need to fix the manual failover. It's not all devices anyway, just the one I'm using at the moment.
> But hey just complain about how it's just impossible and takes so much work instead of actually learning new things.
Too many new things to be exact. Most of them needless. However either people have figured out by now how to work around the ipv6 commitee to simplify things, or they were always there but whoever tried to explain ipv6 to me before had a fetish for enterprise solutions. I distinctly remember being told I need to set up at least 2-3 extra services for my dual wan setup.
Your answers are almost devoid of acronyms and "helper" services that i need to set up and learn because it sounds professional. You almost only included firewall rules :)
This was not my opinion of ipv6 before. Maybe I'll give it a chance in the future. My current setup still works "just fine" though so I need to be very bored to fuck it up.
> "NPt makes perfect sense for SOHO IPv6 Multi-WAN deployments." Wait, they agree with me.
Well yeah, without implementing BGP and controlling your public prefixes its the only way to have multi-WAN deployments, and chances are home users aren't messing with BGP. Most users will get by fine just adopting their WAN-issued prefixes.
> I don't think any of my internets has failed since like 2010... mostly keeping them out of inertia.
So next time you do some big network maintenance just drop your redundant WAN connection, sounds like you haven't really needed it in 14 years (imagine the thousands of dollars you'll save not keeping it another decade and a half!). Just adopt whatever public prefix you have, and life will be simple.
> Your answers are almost devoid of acronyms and "helper" services
Largely because there aren't really many "helper" services needed if you're willing to adopt some pretty basic network designs. Add DNS/mDNS, and suddenly you don't need to care about the specific numbers of things. Just accept SLAAC, which comes with any Linux/BSD distro/MacOS/Windows/whatever IPv6 embedded stack you've got comes out of the box for the last decade+, and suddenly you'll get publicly routable IP addresses. If you want to access SSH on a box, add a firewall rule for its IP and register its IP in a public DNS, and suddenly its accessible anywhere. You can make any host in your network accessible if you want to. Its nice.
> This was not my opinion of ipv6 before. Maybe I'll give it a chance in the future.
I get there's a lot of new acronyms with it digging deep in docs. I get it sounds like there's a million ways to deploy it. There's a lot to know, if you want to get deep in it. Honestly, if you just kind of loosen your reins a little bit, accept the things that are already shipping on the things you've been running for a decade will just work with the newer dynamic stuff, and adopt DNS, it'll probably be perfectly fine. You probably don't need to install/configure dozens of additional things.
> imagine the thousands of dollars you'll save not keeping it another decade and a half!
Uh well, i'm in eastern europe and the fiber i would give up on is in a package with the cell phones and the tv channels, so i think i wouldn't even notice it missing from the bill. And it's all iptv so I don't think I can have tv without the fiber.
The other pipe is business ish (symmetrical, no restrictions on servers) so I'm not giving up on it, I'm using it to give stuff to customers etc.
> I get there's a lot of new acronyms with it digging deep in docs. I get it sounds like there's a million ways to deploy it.
As i said, last time I asked on some forum (maybe hn, maybe ars technica) i got drowned in acronyms. Most of them for extra daemons to handle ... some config for a larger network, i guess.
And believe it or not, I didn't know until today that you can ignore your ISPs prefix and do address translation with ipv6 :) I thought you use what you get and that's all. Because that was the promise of ipv6 wasn't it? No more NAT.
Lots of machines at home and yet having DNS tied to DHCP or running mDNS is too much of a hassle.
I would hate to have to remember even the last octet of all my machines in my house. Instead it's just the simple names. The numbers underneath can all change whenever, it doesn't matter. Until I start calling my kids by an octet a name will be easier to remember instead of "is that north camera 101 or 105 or 113 or..." versus "north-camera.my.net" or "is my pool controller 10.7 or 10.8 or..." Instead it's just pool-pump.my.net.
I mean why would anyone really care to deal with DNS anyways, just a bunch of fluff. Real IT admins just memorize IP addresses. Why would I bother dealing with all that DNS hassle?
If its easier to remember this site by its name, why wouldn't it also be easier to remember what your file share's host is by just remembering its name instead of some collection of digits? Do you remember people by their phone numbers or by their names?
Having functional local DNS is not complicated these days. On tons of systems it comes out of the box, you almost have to go out of your way to not make it work. You need to actively try to not use it.
What you forget is on your average home network only the last byte matters. The first 3 don't change. It's always 192.168.x.y, x is fixed so you only need to remember the y.
Target tried to enter the Canadian market and lost $5.4 billion. Yes it's not a grocer but the idea is similar: Canada is a hard country for foreign companies to enter. The countries is filled with failed foreign entrances: cellular, grocer, clothing brands.
On the other hand, there are plenty of success stories of foreign chains entering Canada. Target's rival Walmart has been reasonably successful in Canada, having over 400 stores. Target made a lot of mistakes entering the Canadian market, starting with leasing locations of dying Canadian chain Zellers and even still running them as Zellers for years, which didn't help building up the Target brand in Canada.
Target's approach was quite similar to what Walmart did in 1994, when Walmart entered the Canadian market.
Walmart took over around a hundred or so of the long-established Woolco stores, and converted them to Walmart stores. The Woolco stores I'm aware of were then replaced with new larger Walmart-built store in the same area within a few years.
I think Target's main problem was more timing rather than execution. In 1994, Canada still had a relatively strong middle class with money to spend, although that would eventually be harmed thanks to NAFTA, excessive government interference in the economy, and excessive immigration. By 2011 when Target showed up, Canada's middle class was already suffering, and it has only gotten much worse since then.
All of the Target stores I ever visited in Canada were decent. The pricing typically wasn't as competitive as Walmart's was, but the Target stores were generally a nicer experience.
They also messed up with their computer system. I forget the details from the account I read, but it had to do with trying to import the entire system from the US, database included, and spending more time fixing errors than actually selling anything. That database (if I recall right) included the sales data they used to predict demand and allocate stock, and it was completely wrong for the new market.
It might have worked if they started with a few stores to work out the kinks and incorporate the data into their planning systems, but they went for a huge launch instead and couldn't keep shelves stocked because nothing was where it needed to be.
Not just foreigners. A few years ago many Canadian restaurants tried to pivot to being grocery stores, but the customers never came in any meaningful way. Canadians are exceptionally brand loyal.
Cell carriage is, indeed, another great example. Many of the home-grown independent telcos in Canada started operating cell networks in the mid-2000s, but they were never able to win over the customers loyal to Bell and Rogers. The CEO of one of those telcos, which remains a strong player in the wired market in my local area, states that venturing into mobile was his biggest mistake.
> Many of the home-grown independent telcos in Canada started operating cell networks in the mid-2000s, but they were never able to win over the customers loyal to Bell and Rogers.
It has nothing to do with loyalty, the coverage of these networks is just bad. I'm on one right now. Canada is a huge sprawling country and many people venture far for camping, to cottages and so on, and they won't go with a cell provider where they lose service 10 mins outside of Toronto.
It's even worse sometimes, coverage in cities adjacent to Toronto, like Oakville, is also sometimes bad. Canada's problem with mobile is sprawl and a largely ineffective regulator.
> It has nothing to do with loyalty, the coverage of these networks is just bad.
They had nationwide agreements. They still do, technically, but no longer operate any cell sites, now essentially being a Bell reseller. Even as a reseller, their customer base hasn't grown in any meaningful way, certainly not beyond the wired customer audience. In fact, I bet you don't even know their names. Nobody in Canada cares to look beyond their loyalty.
What typically happens is that they are just bought up by one of the big 3. I had a great plan with Fido, very reasonable prices and good service, and because they were growing, Rogers bought them up and then all the prices shot up to match Rogers.
> What typically happens is that they are just bought up by one of the big 3.
Perhaps, but as they are owned by the customer (or government in a few cases), that would ultimately be on the customer to decide. If future service, price, or quality was of concern, they could easily reject the deal.
Agreed. If we (Canada) want to make a serious effort at reducing the inflationary expense of groceries, we should start looking at things like the protection racket surrounding our domestic dairy product industry.
But I don't see that happening because that'll lose votes in areas where the Liberal party is weak.
The farm and farm-adjacent population make up such a small segment of the population these days, even in farming areas, that nobody has to appeal to them. However, the government is legally obligated to buy back the quota, which would be a devastating cost. Ain't no politician (outside of those going to crazy town, like Bernier) would ever touch that even with a ten foot pole.
It was done for tobacco in 2009, but the tobacco industry in Canada was already essentially nothing. The cost to get out was still massive, but only a tiny, tiny fraction of what it would cost to get out of dairy, poultry, and eggs.
I don't know how this misconception persists, but Target's Canada failure was entirely Target's fault. They made huge errors in distribution/inventory and the shelves were empty from grand opening. They resolved their inventory issues after their fate had been sealed.
Canadians are risk averse, too afraid to stand out and too eager to put down America and claim to be better than them for any significant change to happen.
Maybe the worst out of the developed countries across all metrics.
Maybe, but it’s also remarkable Canada hasn’t had a bank failure in >100 years. It’s a safe, peaceful and prosperous developed country. Hard to argue that Canada hasn’t done fairly well. I still agree it’s perhaps too risk averse, but I disagree it’s the worst performing of all developed countries in that regard.
It's not tragedy of the commons for the simple reason that it is the creators of the project that're issuing the CVEs. If anything, it was the prior situation that was the real tragedy of the commons- the freeloaders were not contributing resources back to the Linux developers for security assessment.
Now everyone gets to do their own, which they should have been doing in the first place.
But is the system really working usefully in this case? It seems like the intended purpose of CVEs is to actually identify serious (and less serious) exploits, which requires that someone, somewhere do quite a lot of work figuring that out and keeping track of things. But the kernel maintainers didn't sign up for that, so they basically shut things down via malicious compliance--not that I blame them, since nobody is stepping up to do the work and the maintainers already have a job, thank you.
So the tragedy of the commons is that security organizations ended up relying on CVEs as a security standard, without really thinking through who was going to do the dirty work of keeping that system going as it expanded.
<quote>
There’s just one problem – each security vendor has its own database with little to no crossover. Each vendor’s tool generates its own alert for detected vulnerabilities, and these alerts must be manually cross-referenced between the tools to determine if they are separate issues or multiple alerts for the same issue.
</quote>
Some people wanted CVEs as identifiers. Some wanted the CVE most to be dense with actual security bugs (that justified backports, upgrades etc). Some wanted to issue many, often with nice names.
That game has no self-awareness at all. US good, Russians bad, must kill bearded brown people.