The NSE was Suns attempt at a grand SCM system and it was miserably slow (single threaded fuse like COW file system implemented in user space). I did performance work back then, sort of a jack of all trades (filesystem, vm system, networking, you name it) so Sun asked me to look at it. I did and recoiled in horror, it wasn't well thought out for performance.
My buddies in the kernel group were actually starting to quit because they were forced to use the NSE and it made them dramatically less productive. Nerds hate being slowed down.
Once the whole SCM thing crossed my radar screen I was hooked. Someone had a design for how you could have two SCCS files with a common ancestry and they could be put back together. I wrote something called smoosh that basically zippered them together.
Nobody cared. So I looked harder at the NSE and realized it was SCCS under the covers. I built a pile of perl that gave birth to the clone/pull/push model (though I bundled all of that into one command called resync). It wasn't truly distributed in that the "protocol" was NFS, I just didn't do that part, but the model was the git model you are used to now minus changesets.
I made all that work with the NSE, you could bridge in and out and one by one the kernel guys gave up on NSE and moved to nselite. This was during the Solaris 5.0 bringup.
I was forced to stop developing nselite by the VP of the tools group because by this time Sun knew that nselite won and NSE lost so they ramped up a 8 person team to rewrite my perl in C++ (Evan later wrote a paper basically saying that was an awful idea). They took smoosh.c and never modified it, just stripped my history off (yeah, some bad blood).
Their stuff wasn't ready so I kept working but that made them look bad, one guy with some perl scripts outpacing 8 people with a supposedly better language. So their VP came over and said "Larry, this went all the way up to Scooter, if you do one more release you're fired" and set back SCM development almost a decade, that was ~1991 and I didn't start BitKeeper until 1998. There is no doubt in my mind that if they had left me alone they would have the first DVCS.
Fun times, I went off and did clusters in the hardware part of the company.
I'm sure sure about a hard limit in the x509 standard (would need to dig into the RFCs) - but the BadSSL site has two test domains that have certificates with 1,000 and 10,000 SANs respectively:
1,000 works in Firefox and Chromium, but 10,000 gives `SSL_ERROR_RX_MALFORMED_HANDSHAKE` in Firefox, and `ERR_SSL_PROTOCOL_ERROR` in Chromium. OpenSSL won't connect to it either - it gives `read_state_machine:excessive message size:ssl/statem/statem.c:610`
So in practical terms, the answer seems to be somewhere between the 1,000 and 10,000.
Since it keeps getting trotted out onto this site: Palladium is a far-right magazine masquerading as an independent publication. It's bankrolled by Peter Thiel, and its founders and editors are a veritable "who's who" of reactionary (and explicitly white supremacist[1]) thought leader types.
First I would use unlec.com to determine where it is currently allocated. The SPID/OCN tells you who has it. SPID = Service Provider ID; OCN = Operating Company Name.
Then look at the LNP history, which is the history of who and when the number was assigned/re-assigned over the years.
Tell both companies that you will be involving the FCC and try to reach the "porting group" who will be able to fix this. Porting problems happen all the time, even with 99% of ports (that might be an optimistic number) happening in a nearly-automatic fashion. (EDIT: I mean the porting group at each company, not the FCC).
The exposure, the name recognition, the PR coup that this would be ... would dwarf every effort we have ever made in over 20 years of trying to publicize our company.
Seriously: If you work for any of these "aggrieved" content providers and if you really want me to buy the Aspen house ten years early, dear god please sue us.
The metaverse stuff is really, really embarrassing. Second Life has existed for 20 years and it's a fun novelty. Adding advertising and branded content and making it cost more because of high end hardware requirements and making it slower and more difficult to interface with because it's VR/AR instead of using existing interfaces is not an improvement; just like adding branded content and sticking it in the skeletal husk of a bad shooter game for 12 year olds wasn't an improvement when Epic did it. All the CEOs who buy into this metaverse shit keep talking about the universe of possibilities, but the only possibility they're pursuing is building a Times Square Wal-Mart.
Even crazier, most of them approvingly point to the execrable "Ready Player One" as an example of a vision to deliver on. No, I'm sorry, a horny 15 year old shaving his body hair so he can be more aerodynamic in VR while engaging in extended self-congratulatory monologues about what a Nice Guy he is for not being repulsed by his "Rubenesque" girlfriend while he recites lines from Ghostbusters in a series of completely incoherent "memba this???" vignettes, is not a vision for the future.
It's a bummer because I think there probably are legitimate uses of VR/AR telepresence as the next frontier of video calling, which would seem to be right in line with Facebook's stated mission of connecting the world.
But no, we'll get an exceedingly shitty videogame instead. Can't wait for them to power it all by NFTs.
Have you ever heard of "The Narcissist's Prayer"? It goes like this:
That didn't happen.
And if it did, it wasn't that bad.
And if it was, that's not a big deal.
And if it is, that's not my fault.
And if it was, I didn't mean it.
And if I did...
You deserved it.
Tether defenders are really working their way through the steps here.
18 months ago, it was "That didn't happen." (Tether is 100% backed by USD cash.)
6 months ago, it "wasn't that bad." (It might not be 100% USD cash, but it's cash-equivalent assets like short-term commercial paper.)
Now that there's strong evidence the commercial paper is just fake money shuffling between Tether/Binfinex/other shady crypto investments we get "that's not a big deal." (Look at the way banks work! They only need 4% collateral! Tether's probably got at least that much...)
Next step is finding out that their actual liquidity isn't capable of holding up under a real-life stress test, and the defenders will be talking about "not my fault." (This was a once-in-a-lifetime crash, they couldn't have foreseen it, crypto's still way better than the fiat banking system!)
When thousands of people lose their retirements in a gigantic defi crash, it'll be "you deserved it." (Everyone knows crypto is risky, you shouldn't have believed Tether was the same as USD.)
They discuss the dramatic increase in the need for titanium parts around 18 minutes into the first video. https://youtu.be/lapFQl6RezA?t=1090
When aluminum and carbon are in direct contact, galvanic corrosion is an issue. The only way they could make a plane with carbon fiber wings, fuselage, and empennage, was to replace most metallic elements with titanium. The final 787 is 15% titanium by weight.
Titanium is tough to work with, and I can see how problems would arise when you redesign what must be thousands of parts.
Pringles are not chips. They are mathematically precise reifications of idealized perfection. It has nothing to do with potatoes and binders, those are only incidental. It's all about the libidinal act of destroying perfect objects with your mouth.
I have a pretty stupid bot set up with Asterisk. I think the record is 17 minutes, and the bot even repeated the script. When I get bored I put up some calls:
IIRC there isn't a problem for most of the flight; but right as you're ascending/descending your phone can end up getting a very weak line-of-sight connection to a whole bunch of cell towers at once, which causes a few different problems, but all of which come down to "it makes both your phone, and all the towers, shout really loudly at one-another to try to achieve a circuit." Which, sure, means that there might be EM interference (on bands ATC doesn't even use, but which the pilots might like to switch to in event of emergency.)
But, more importantly, it puts your phone's radio through an unusual high-power-draw situation that the phone's manufacturer may not have bothered testing for, which can make phone batteries explode that might not have otherwise ever exploded.
Oh, and also, a plane-load of people whose phones are all ranging hogs circuits on a bunch of towers at once (for no productive purpose, since the phones don't have high-enough SNR to actually communicate anything useful with any of the towers they can "see"), so the cellular service providers have politely asked the FAA to get people to not do that.
A key thing to know is that SMSes do other things than just hand text to a program to display it. There is, for example, Flash (Class 0) SMS, which has the semantics that it both:
1. must display over whatever the user is doing (sort of like a Windows elevation prompt) and
2. must not be handed to userland in a way that it could be automatically recorded or persisted, other than by the user's explicit action.
Giving SpringBoard the ability to render SMSes is really the only way to implement Flash SMS in a way that adheres to its semantics.
There are other types of SMSes as well—WAP Push messages, for example, or WMI (voicemail indicator) Activation messages. Heck, your carrier can even use SMSes to directly write data to your SIM card. These aren't so clearly a layering violation as Flash SMS, as they are just pure OS-layer concerns; but if you're already implementing a kernel library for "SMSes triggering OS-level functionality" for Flash SMS and the like, you may as well put the code to handle these cases in there as well.
> Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.
America’s cities are based on zoning laws designed to do racism in 1900, and the rest is based on the federal highway system. Not very free market either way.
For professional simulators working on software for RISC-V hardware there are Spike [0], rv8 [1], and QEMU [2] are popular.
For educational purposes, Venus [3,4], RARS [5], and RIPES [6] are popular.
A fuller list can be found at [7].
Disclaimer: I am the maintainer for RARS. I have my finger on the pulse of the education simulator scene so if you want a fuller list of educational simulators, I can wrangle those URLs.
«
The solution we use at Google is that we watch for I/O errors using a completely different process that is responsible for monitoring
machine health. It used to scrape dmesg, but we now arrange to have I/O errors get sent via a netlink channel to the machine health monitoring daemon.
»
He later says that the netlink channel stuff was never submitted to the upstream kernel.
It all feels like a situation where the people maintaining this code knew deep down that it wasn't really up to scratch, but were sufficiently used to workarounds ("use direct io", "scrape dmesg") that they no longer thought of it as a problem.
I know HN is kind of a safe space for engineers to express their (sometimes arrogant or poorly informed) opinions about other people's fields.
But this seems over-the-top. Who are these "ridiculous" people in New York, whose grasp of the situation around why this particular font ever came to be used in NY signage is so laughably feeble and inferior to the commenter's own?
There may be no mystery worth solving, but neither is there a clearly identifiable moment when a shopkeeper selected the font for the first time. In high-profile design, in contrast, historical moments like that are often traceable—they do have an author.
At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.
Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.
On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.
Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:
Yeah, this is the typical dismissal of anything not STEM!!STEM!!
In reality, technological invention has always gone hand-in-hand with progress in our understanding of how to organise a just and productive society. It's sometimes harder to point at specific examples because this change happened more gradually, but ignorance of this progress doesn't legitimise a wholesale dismissal.
Concepts such as the rule of law, democracy, capitalism etc. didn't appear out of nowhere, nor were they always-existing "goodery truthiness". And there's no technology that could be identified as central to their establishment.
In fact, I'm pretty sure I'd rather live in a society with the technology of the stone age and today's understanding of law&justice, than a society with the technology of today and the stone age's morality.
In as far as technology had an impact on such progress, Jared Diamond argues that it was mostly in increasing the productivity of farming, allowing more and more people to not work the fields, live in cities, and actually start thinking.
There's something delightfully twenty-first century about a project to replace Western Philosophy with a dozen or so definitions, shortcut heuristics and simplistic approximations.
My buddies in the kernel group were actually starting to quit because they were forced to use the NSE and it made them dramatically less productive. Nerds hate being slowed down.
Once the whole SCM thing crossed my radar screen I was hooked. Someone had a design for how you could have two SCCS files with a common ancestry and they could be put back together. I wrote something called smoosh that basically zippered them together.
Nobody cared. So I looked harder at the NSE and realized it was SCCS under the covers. I built a pile of perl that gave birth to the clone/pull/push model (though I bundled all of that into one command called resync). It wasn't truly distributed in that the "protocol" was NFS, I just didn't do that part, but the model was the git model you are used to now minus changesets.
I made all that work with the NSE, you could bridge in and out and one by one the kernel guys gave up on NSE and moved to nselite. This was during the Solaris 5.0 bringup.
I still have the readme here: http://mcvoy.com/lm/nselite/README and here are some stats from the 2000th resync inside of Sun: http://mcvoy.com/lm/nselite/2000.txt
I was forced to stop developing nselite by the VP of the tools group because by this time Sun knew that nselite won and NSE lost so they ramped up a 8 person team to rewrite my perl in C++ (Evan later wrote a paper basically saying that was an awful idea). They took smoosh.c and never modified it, just stripped my history off (yeah, some bad blood).
Their stuff wasn't ready so I kept working but that made them look bad, one guy with some perl scripts outpacing 8 people with a supposedly better language. So their VP came over and said "Larry, this went all the way up to Scooter, if you do one more release you're fired" and set back SCM development almost a decade, that was ~1991 and I didn't start BitKeeper until 1998. There is no doubt in my mind that if they had left me alone they would have the first DVCS.
Fun times, I went off and did clusters in the hardware part of the company.