xtrapolate

> "Pass-by-reference: The formal parameter merely acts as an alias for the actual parameter."

"Alias" means nothing to a CPU, nor is it an ABI. At the core, passing by reference is usually implemented by providing the "address-of" something to a function (for example). The "address-of" itself, is passed by value. Going by that logic, everything everywhere is passed by value.

Anybody aware of any browsers making this a trivial workflow? Any comprehensive list of recommended plugins? Anything targeting mobile platforms?

I've been using this exact comparison, to pitch against web bloat (and bloated technology in general). Some more fantastic demos: https://www.youtube.com/results?search_query=farbrausch

> "Guess what computers excel at? Driving consistently on consistent highways."

Possibly on paper. In reality, as of right now, computers are clearly far from excelling at this specific task.

A video of the team at Ghibli having a late dinner together, as they near the release date of one of their bigger features: https://www.youtube.com/watch?v=0BPTNdmdJSc

They were working hard in that studio, with passion and conviction.

> "No comments on how crazy this viewpoint is?"

Lucky you're here!

> "The state is anti-innovation"

Not in Sweden, it isn't. Ad hominem all the way.

> "They're arguing that a monopoly of the state is better than a "monopoly" of four different companies"

There are examples in recent history that support this model: https://en.wikipedia.org/wiki/1983_Israel_bank_stock_crisis

> "even a small amount of data processing will make your program CPU bound pretty quickly"

I don't know what "a small amount" means. You are bound by hardware (cores, hyper-threading). It simply makes no sense to spawn 32 threads executing computation intensive code (no IO), on a machine with 2 cores.

> "In languages that rely on the OS to schedule threads, the situation is much more dire, even with the great performance of NPTL on linux. Context switches are more expensive since they have to go to the kernel. And so on."

Which is a supporting argument against using a thread-per-connection. Use a reactor instead (IOCP, epoll, etc).

> "Generally if you implement green threads, such as in Erlang, Ruby, or Go, you can do "thread per request" very efficiently and in a cache friendly way - such that you should achieve the same performance as an event based model."

"Green threads" are not operating system threads, they shouldn't be confused. The runtime will still need some way to handle blocking IO, so under the hood, you will often find some sort of reactor/thread-pool/event-driven-system making it all work (it's simply abstracted for you by the runtime). Bottom line, a "Green-thread-per-connection" is not "OS-thread-per-connection.".

> "It's just not trendy."

The "thread-per-connection" model doesn't scale. It's simply not resource-efficient in any way.

> "They could have designed for privacy and real-time deletion of data"

Actually, they could not. If data is geo-replicated across multiple clusters, spread all over the place, divided into hot and cold storage layers - it's crystal clear you can't perform "real time deletion of data". Instantaneous deletion of all data, leaving no trace behind, can not happen under such complex constraints.

Do you think it's as easy as "rm"-ing a file away? Your data is kept internally in a multitude of different databases. Parts of it sitting in cold storage. Log files, caches. That data is split across thousands of different nodes. Each system has different data retention policies. Some databases don't permit removal of a specific record - the records must "expire" first. It really does take time to delete data.

This proposal is a compromise. Wouldn't a specific metadata/heartbeat "packet", routinely dispatched by the involved parties, serve a better solution?

My personal stand is to prohibit exposing any metadata on the connection whatsoever, but given the counterarguments, I don't think the proposed solution is ideal.

Why are you being down-voted? What's going on? This case has been going on for years; he has been through hell. How is this a proper reimbursement?

Edit: Forgot it's yet another echo chamber community.

You'll need to define a clear set of criteria. All of the aforementioned providers have similarities, and differences. Requirements, costs, SLA, support, availability, APIs, redundancy... it's an infinite list that you'll have to narrow down yourself.

You're free to do as you please here. You don't have to use malloc()/free(), just implement your own LIBRARY_Alloc()/LIBRARY_Free()/LIBRARY_GetMemorySizeBytes() :)

I appreciate the insights, and respect OP's point of view, but some of these "takes" are extremely dichotomous.

> "Microsoft - I don’t know that there’s much about their culture or current business that’s particularly admirable."

Really? Absolutely nothing at all about Microsoft's culture/business practices is "particularly admirable" to OP?

Blocking the whole country is an interesting move, mostly because it has the potential to generate a much greater public outcry than simply masking away the few specific books in question, putting a greater public pressure to reevaluate the entire legal constructs surrounding these issues. It's a display of standing for your principles without compromise.

As a business person, you're going to have to sell yourself/your services to other people. Perhaps that's not too different from pitching yourself to an "anonymous promotions committee"?

Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!

Sure, you can call your "ex-coworkers at Microsoft" (most of which are irrelevant to debugging/verifying this issue) - or, you can just spend some time reading the documentation, as previously suggested.

The coherency issues are your "tread lightly" warning. The docs regarding FlushViewOfFile expand on this specific issue:

Flushing a range of a mapped view initiates writing of dirty pages within that range to the disk. Dirty pages are those whose contents have changed since the file view was mapped. The FlushViewOfFile function does not flush the file metadata, and it does not wait to return until the changes are flushed from the underlying hardware disk cache and physically written to disk. To flush all the dirty pages plus the metadata for the file and ensure that they are physically written to disk, call FlushViewOfFile and then call the FlushFileBuffers function.

So, after carefully reading this documentation, we can clearly conclude OP's pull-request is actually missing a call to FlushViewOfFile prior to calling FlushFileBuffers.

Answer is: "none of the above".

Coherency is covered by the WinAPI documentation (check the remarks section). Always RTFM.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

  Twitter was twitter before they had all those people.

Sure, but it can't scale without them. How exactly is Twitter supposed to pay the bills? People use this platform because, for the most part, the basic premise is entirely free. How else can they fund the infrastructure/R&D costs?

People make mistakes, "punishment" isn't the way forward here. There are alternatives out there to Intel, but kindly remember that other chip makers also released hardware that is susceptible. Also, you can trust this won't be the last time issues such as this come up.

This same logic can literally be applied to anyone working on anything. Engineers, carpenters, pilots, literally anyone.

I bet there are many people who know everything about "XMLHttpRequest", but know nothing about congestion control. Or how a network stack comes together...

You do realize "XMLHttpRequest" wasn't even a thing until several years ago, and it's safe to assume further down the road it may well be phased out (in favor of better/more secure APIs).

Instead of asking about "XMLHttpRequest", wouldn't it be better to talk about the general need for "websites" to communicate with a backend on demand, at runtime, after everything has been loaded and rendered? Or, put "XMLHttpRequest" on the table, and talk about how one would implement such an API within the context of a browser?

When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: https://www.youtube.com/watch?v=Y3n3c_8Nn2Y - as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes.

Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective.

It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.

If your clients trust the self-signed certificates (by updating their certificate stores, adding up a self-signed root CA), then, as of today, as far as I'm aware there won't be any warnings. No guarantees that this situation won't change further down the road.

  Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years?

You can use self-signed certificates. Your clients will have to trust them (by updating their stores). That's hardly an ideal solution (deployment and security wise).

More broadly speaking, you can't rely on anything to stay the same in 30 years, in terms of infrastructure. Many companies therefore deliver both the devices themselves, as-well as the systems to control them (ie. custom laptops/tablets). More costly for everyone involved.

The doctor example is great, but where do we draw the line exactly? Offloading some aspects of your work by utilising other people and their expertise is surely the way to go, but there's a balance to be kept. Sticking to your example, good secretaries (much like good engineers) are expensive, and are hard to come by - isn't that enough to explain why public health services skimp on those?

You could argue that in an ideal world/society, everyone would just do those few specific things they're really good at/love, and nothing else.

  In a modern office there are no specialist typists; we all need to be able to pick our way around a keyboard. PowerPoint has made amateur slide designers of everyone. Once a slide would be produced by a professional, because no one else had the necessary equipment or training. Now anyone can have a go — and they do.

I'm struggling to follow. Putting your thoughts down on a piece of paper is something we all need to be able to do. Do people waste time doing it? Sure, some people will waste some time. A myriad of reasons to it. Boredom, clumsiness, a strong need to let out your creative sides, just to name a few.

Perhaps this entire piece comes down to being more aware of the things that distract you. The side quests that often start small, but end up consuming large portions of your time.

  In a modern office there are no specialist typists

Sure, in a modern office you won't come across many such people (amongst other esoteric examples). But there's a counter argument here - forcefully introducing additional bureaucracy by proxies is just as hurtful, if not more.

  I have been working on Snow, a unit testing library for C.

OP requires a unit testing library for C, so they've written one. What is the alternative solution you propose? The framework itself may appear complex, but the entire end goal here is to provide simple/abstract tools to write tests in a readable/self-documenting manner. The framework itself is the mean, not the end goal.

Decoupling code/infrastructure is not a bad practice. As it so often turns out to be, "Microservices"/"Monoliths" mean different things to different people, and your mileage may vary. Difficulties may be introduced going either way.

Choosing the right tool for the job is difficult, there are many variables at play. There's a lot of value to people sharing their perspectives/experience about these issues. At the same time, I think the overall discussion shouldn't be so dichotomous.