MCP should have been an HTTP protocol from the get-go.
11,713 karma · joined June 29, 2012
It's idiotic. Unless the goal is to waste money and opportunities, then it's brilliant.
Between spy sats and drones we don't need a spy plane, not even a mach 6 spy drone.
Well, maybe some are like that. They'll stop coming to your parties, or you'll stop inviting them, or you already know they are like this so you won't even invite them. The rest will keep showing up -- they're the fun ones!
You want N people. Assume 1/2 won't show. Invite 2N people. Either ask people to bring a bit of food, or provide food for 1.5xN and if you get only N then you'll have leftovers.
> - Unreciprocated $100s of dollars spent is non sustainable, and lowkey feels kinda like buying others friendship
If you have the disposable invome for it then it's its own reward, and you're not buying friends: you're helping them make new friends with your other guests, and this is something they'll appreciate about you. They might or might not reciprocate because as we've seen in this thread, many are not into hosting.
> - mixing circles -- people are often isolating their friend groups into niches (pickelball friends, church friends, D&D friends...)
Mixing is half the point!!
> - And IMO the overarching issue in America that creates so many problems -- Everyone is so overworked that they don't have the energy/capactity to do good things: Exercise, and hosting parties being two examples.
That's what long weekends are for, so host a party on a day in a long weekend.
| Because the length of a month or year changes from one month or year to the next, ambiguities can arise when shifting a date by months and/or years. For example, what is the date one year after 2024-02-29? Is it 2025-02-28 or 2025-03-01? Or what is the date that is two months after 2023-12-31? Is it 2024-02-29 or 2024-03-02? There is no consensus on how to resolve this ambiguity, so the "ceiling" and "floor" modifiers (14 and 15) are available to let the programmer decide. If the next modifier after a time shift is "ceiling", then any ambiguity in the date is resolved by choosing the later date. The "floor" modifier resolves ambiguities by resolving to the last day of the previous month. The default behavior is "ceiling".
> After the disaster that was Viking. They might have gone 32bit x86, 64bit Alpha. DEC was desprate for Alpha buyers and would have made them a good deal. But they double down on going all in on SPARC and UltraSPARC confirmed them in this being the right solution.
The only reasonable option in the early- to mid-00s was x86_64, especially after around 2004. Even just before x86_64, having a conversation with AMD about it would have been enough -- x86 was the present and future of the industry, and all that was needed was for this to be accepted by Sun.
More like
There are only two hard things in
computer science. Naming, cache
invalidation, and off-by-one bugs.UI time elements have to be presented in the user's TZ. In the DB one should store timestamptz in UTC for all things, and maybe also timestamptz in non-UTC TZs for user input (e.g., in a calendaring app).
> I think he didn't realize how externally this would look for the viability of Solaris on x86.
I'd love to see that. Yeah, it didn't go well. It was a disaster.
> > - Closing Sun PS (professional services). Bad bad move, possibly the worst of them.
> Can you give some context. I am interested in Sun history and I don't know that one.
In 2004 Sun closed Sun PS. Well, it... didn't go away completely in that what was left became Sun Client Solutions, but the lay-offs IIRC hurt that unit a great deal.
> (Edit: I see you mean Sparc T1, but those chips were trash, they were not to late. They were good marketing above good product)
Yeah, and it was too late to edit my comment. My bad. But yes. The SPARC folks had some great ideas in the T line, but it was a) way too late, b) didn't have access to latest node size, so it wasn't going to be great-performing, c) performance sucked.
> Also StorageTek.
Eh, not sure about that. The acquisitions of StorageTek and Procom were the only ones I can think of where Sun actually managed to capitalize on what it acquired. The Procom side contributed a Microsoft RPC stack and an SMB/CIFS stack, which was in fact integrated into Solaris. The StorageTek side became the Sun storage appliance.
In 2009 Sun's greatest hope was that its systems work on the storage appliance was going to succeed and save it. That stack was far far better than NetApp's and anyone else's. Of course, that didn't materialize in time, and we know the rest of the story.
With all these mistakes there's enough there to think about many possible alternative paths Sun could have taken, but... there's no point, it's done. I don't recommend dwelling upon much unless you're building a business school case study, and for that I think Sun is an excellent case candidate, especially given that you can compare Sun to Apple and others, so you can see what could have been.
My diagnostic is that McNealy checked out with the 2001 crisis, Schwartz was just a really, really bad steward, and no one wanted to take the hatchet to the vendor lock-in products that were holding Sun back. In 2002 the right thing to have done was to announce less investment in SPARC and start winding it down -- that would have freed many billions for other things later in the 00s, and it would have saved Sun PS. But perhaps in 2002 Sun didn't have the systems expertise needed for the transformation it needed to undertake.
Meanwhile Apple was never wedded to an ISA for long, and even now that they make their own CPUs they could easily switch if they had to. I say 'easily', but it's monstrously expensive, yet for Apple it's totally doable. Steve Jobs wasn't afraid of disrupting Apple itself. That's what Sun needed: internal disruption.
First, anyone can participate. The only cost is the value of your time.
Second, yes, there are the usual suspects -- the ones who've decided to spend a lot of their time on whatever the area of tech we're talking about.
Third, working groups have charters that delineate what RFCs they will publish. Sometimes the work runs out. Sometimes the people run out of energy. Sometimes the tech is 'done', at least for a while. Then the WGs shut down.
Fourth, sometimes new work gets brought to the IETF in an area where the relevant WG has concluded, so then a new WG _may_ get spun up to take on that work.
If you segregate content-type/language by end-point then the variability goes away. But now you have a plethora of end-points. The complexity can get moved around, and in this particular case the complexity for the caching layer can be removed, but the complexity isn't gone.
TFA makes me think that your argument is stronger than I would have thought yesterday, though I still prefer to have Accept/Content-Type negotiation. Sibling's comment about negotiation is on-point.
IIRC it was $1bn or so, and Sun only had like $6bn in the bank. It was a desperate play when Sun needed help.
2. Yes, unless you need much more structure, then you have to think about ASN.1, XDR, PB, JSON, etc.
3. XDR is a perfectly reasonable basis for an ASN.1 encoding rules family. In fact, PER/OER resemble XDR in many ways. XDR is only simple because a) it's way simpler than the supposedly-simple tag-length-value encodings that ASN.1 came with originally, and b) Sun actually built a solid codegen tool (rpcgen(1)) for it. Never underestimate the value of having excellent tooling as a way of simplifying things :)
4. Alg. agility needs to be tied to the signing keys, not allowed to vary in the headers. Apart from that, you do need alg. agility, so its complexity can be minimized, but not made to disappear.
5. No, because TLS only establishes a channel between two entities, but here we have three or more entities: the two end-points of a TLS connection + all the trusted third parties. The trusted third parties need to communicate to entities they have no direct connection/channel to, and having those pairs of peers initiate connections to get those items is actually quite complex for reasons.
5. It really is the case that signed tokens are extremely handy and simpler than not having them -- it's just that getting signed tokens right has proved tricky in part due to advances in cryptanalysis exposing design mistakes no one knew they were making decades ago.
But it does have the "arbitrary document aspect" when you add the desire for site-local claims.
> JSON solves it by being a data structure first and last.
I'd say that JSON solves it by being remarkably simpler than XML and by having become ubiquitous.
Your points about HTML... keep in mind that HTML is for humans, but what we're talking about here is for programs.
Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?
Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...
What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.
I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.
I think that hints at the problem space being... large and complex and requiring large and complex solutions.
What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.
Maybe if the changes you're doing are small and cheap, sure. But if they are invasive and costly...
So you can elide some details when you talk to leadership, investors, and regulators, but you can't elide everything.