Hi! I'm one of the founders of dotMeow, and it's been a long road to get to the point that we're willing to stake our reputations on a crowdfunding campaign. From applying to the applicant support program (we believe we were one of the first, if not the first organization accepted) to working out financial plans and overall strategy to achieve NIS2 compliance on a shoestring budget, it's been a year and a half of effort to reach where we are now.
It's quite late here in Belgium, so I'm about to go to sleep, but in the morning, I'll happily answer any questions people have about the project.
The sad thing is, this is one of the rhetorical flourishes that gets drilled into you in debate and comms education. ChatGPT picked it up because it's extremely common.
A few people have called us on this, but it's simply not true. The copy was all written by hand; the only machine assistance here is XCompose (you, too, can type an em-dash!).
It turns out that when everybody involved is some level of techie and you're targeting a sort of "corporate bland" tone so that you look professional and trustworthy by modeling your communications on other successful kickstarters, it comes out looking similar to what other marketing copy looks like, which is precisely what all of the LLMs were trained on.
As much as I dislike mandatory certification, I can understand the need for it in wireless battery powered devices: a malfunctioning decide can talk the battery life if everything within range, and most consumers aren't equipped to realize that this is happening much less identify the device that's causing the problem
Perhaps the solution is to make the spec open but make using the trademark contingent on certification (much like USB, for example)
Ehh, not really. OSI layer 5 was responsible for managing multiple non-overlapping sessions within a single transport stream, and routing those sessions to specific applications. This is precisely what HTTP/1.1 did (though the accept, content-type, accept-encoding, and transfer-encoding headers are really an implementation of layer 6); QUIC, on the other hand, covers the same layers that TCP does (3-5) plus the aforementioned layer 6.
I recommend actually reading X.200 (the specification of the OSI model) at some point: it's quite approachable (especially for an ITU spec, which are notoriously dense reading), and will quickly make you realize how silly it is that we still use it as a reference for modern stacks.
In that case, you don't want cloud; you want an MSP, whose core competence is running those IT services. They, in turn, have the skills to colo a rack at a DC or to manage rented servers, amortized across a number of clients.
In practice, there are two situations where cloud makes sense:
1. You infrequently need to handle traffic that unpredictably bursts to a large multiple of your baseline. (Consider: you can over provision your baseline infrastructure by an order of magnitude before you reach cloud costs)
2. Your organization is dysfunctional in a way that makes provisioning resources extremely difficult but cloud can provide an end run around that dysfunction.
Note that both situations are quite rare. most industries that handle that sort of large burst are very predictable: event management know when a client will be large and provision ticket sales infra accordingly, e-commerce knows when the big sale days will be, and so on. In the second case, whatever organizational dysfunction caused the cloud to be appealing will likely wrap itself around the cloud initiative as well.
I recall reading somewhere that the entire point of solitaire (at least the original implementation that came with windows 3) was to teach users how to click and drag, so I'm not surprised that it was good for teaching your colleague how to use a mouse
OSI's session layer did very little more than TCP/UDP port numbers; in the OSI model you would open a connection to a machine, then use that connection to open a session to a particular application.
X.400 was a nice idea, but the ideal of having a single global directory predates security. I can understand why it never happened
On X.509, the spec spends two chapters on attribute certificates, which I've never seen used in the wild. It's a shame; identity certificates do a terrible job at authentication
Looking at a chart of the S&P 500 over decades, it's hard to see how anyone could make money by betting on corporations only being interested in short term results.
The S&P 500 is a list. 80+% of the companies on that list when it started are no longer on it.
Betting on business in general over long time periods tends to be a winning proposition. Betting on an individual company tends to be less of a winner in general.
Businesses do tend to fail eventually. Their business model become obsolete, the market for their product fades away, they strangle themselves with bureaucracy, they zig instead of zag. That isn't short-term-itis.
But you cannot grow a small company into a large one by concentrating on short term profits. The S&P 500 is composed of 500 large companies.
Imagine if you were selling MSFT short every quarter since they IPO'd in the '80s.
It's quite late here in Belgium, so I'm about to go to sleep, but in the morning, I'll happily answer any questions people have about the project.