From my anecdotal observation this is true. Gun sales are also growing among demographics not typically associated with gun ownership (non-white, non-conservative.)
Legal wishes to remind you that that statement always needs this accompanying statement.
The word "better" does not imply a commitment towards customers and/or investors.
*The word "do" should not be seen as referring to the taking of any specific course of action which may or may not yield tangible change.
*The word "can" does not signify a concrete ability and is not forward-looking.
*The word "We" should not be interpreted as Canonical Ltd. nor any of its subsidiaries or affiliated entities.
Except he had a perfectly legitimate point there, as far as I understand, he just utterly botched the explanation.
There's a big difference between "is" and "was". Which is what he should have said. There were no semantic games in that particular statement, in stark contrast to some of the other things he said.
> There's always the risk that the West might internally reject the scientific revolution.
In the US I am pretty sure we are already on the decline.
I think it has to do with, during the industrial revolution and post-war, huge scientific advancements and tech grew the economy, fed capitalism by means of providing new desirable goods to consumers (e.g. dishwashers, nicer cars, etc.)
I wonder if we've reached a "peak" of consumer comfort where advances in science/ tech/ medicine are no longer frequent/ impactful enough to meaningfully satisfy consumers, (why do we care about exploring Mars?) so it's easy for people to reject it and say "we don't need science."
I feel we're on decline, because "science, bitch" is used to harass people into doing something they don't want or not ready. And people generally don't like to be harassed, they begin to resist no matter how reasonable things you're talking about are.
I wish society could pick its battles more carefully.
As a European who have lived in the US, I have been of the opinion that the US have been in decline for several decades. I think there is a combination of over reliance of capitalism to solve problems which seemingly can’t be solved well that way: universal healthcare, environmental management, education, urban planning, crime (prisons) etc, and the culture buying into the “American way” which in fact doesn’t provide the social mobility it claims nor makes the population better off, if you remove the richest from the equation. If I wasn’t so busy with other stuff I would be interested in doing research around this.
Agree with sentiments of the parent comment. I believe the prestige and social standing of physics (and, in part, the academia as a whole) is founded in the truly transformational technological advances -- say, the transistor -- made in the past decades.
Problematically, to secure funding today, one is essentially expected to frame every condensed-matter experiment as the next transistor. Not only in grant applications, but increasingly also in the abstract and opening paragraphs of research articles. There's a marked contrast with older research articles in physics, which usually go straight to disseminating the results. (Needless to say that I prefer the old style.)
As a result, a great deal of funding and attention is allocated towards projects that simultaneously 1) Will not improve the quality of life of anyone, even in the long term. 2) Are "de-risked" to such extent that no new scientific insights can come out of them.
I studied physics because I liked it and the way it describes our world. I then went for a PhD and slowly realized that physics (except a few areas) is basically dead. Particle physics for instance deal with completely outwordly stuff, akin to planning a family trip to Jupiter. Sure, it may happen someday but there are more present things.
I got my PhD and left academia (because of this and petty politics around photocopier paper costs) and the only part I really miss is the teaching and the bright minds.
I agree, for a couple reasons. One, while you usually have to deal with a cross toolchain (usually intel-> ARM) it's easier to build and debug on a target board versus booting and rebooting your PC to see if you did everything right. Also the
I've used debootstrap to build a Debian distro for ARM with a custom kernel (for an Olimex board target or Beaglebone.) That's very hands-off and not nearly the same "depth" as LFS. The next step was taking the same kernel and building a busybox-based rootfs. Then I had to make my own PID 1 and do init work to bring up services such as networking on boot which was very educational, yet busybox provides most of the "lego bricks" that you're not left writing too much from scratch.
Building to an embedded target also allows one to punt on the most annoying and complex parts of a desktop linux distro, such as the desktop environment, audio/video drivers, UEFI bootloader, etc. Building a semi-custom (e.g. Arch or Debian/debootstrap, Buildroot or OpenEmbedded) headless distro was what I'd call a "shallow dive" or gentle introduction to more of Linux's inner workings without having to understand every bit in order to get a running system.
This sounds a bit like the custom bicycle frame builder phenomenon as well. Well-known builders/shops can have years-long wait lists and their builds will go for 2x, 5x or 10x the cost of a top of the line mainstream model - 10s of thousands of $$.
Granted each one is built by hand so the artisanal craft is easy to appreciate.
But exclusivity is there, because these shops are building less than a dozen bikes per year. If you got your hands on one, wow it will turn heads when you roll up to the bier garden at the CX race.
I was curious, and since the author of this answer provided links to what they called leaks [1], it's not difficult to download both the leak and ReactOS source [2] and look for similarities. So, out of curiosity, that's what I did.
I started poking at some source files at random in ntoskernel, and it only took a minute to get some "hits" from the ReactOS source:
Now that said, I have no idea what I'm looking for, or if this is significant. But since we have the source for both, it seems we can do better than speculate w/r/t how much code is similar between them. I know that does not prove copying but I think the author's point can't be blindly dismissed.
I do not wish to view the leaked copies of Windows source code, unfortunately. It does have potential legal ramifications, in the United States. If someone who doesn't care can attempt to audit it, that would be absolutely great.
That said, KiInitializeContextThread isn't 'secret' enough to not appear, it is a well-known bit of internals. Here you can find some docs about it on Microsoft's own website, albeit I have no idea if this is present anywhere on there anymore.
If Microsoft cared, they wouldn’t be hosting that on their very own servers.
GitHub belongs to Microsoft. They could pull that down at any time just because they feel like it. But they haven’t. That’s a pretty solid sign that there’s not any legal consequence to viewing it.
Well, my paranoid 99% says that they could keep it online on purpose so that all people viewing it fall in a legal disadvantage position. Removing that code would achieve nothing in secrecy today compared to the legal leverage they can get tomorrow by keeping it online.
For what it's worth, it's not just Microsoft who care. You're not allowed[1] to contribute to Wine if you've ever seen the leaked Windows source code. I think it's weird that they consider your mind to be "tainted" forever, but whatever. I guess they want to be cautious.
(You're also not allowed to contribute to the Wine CRT if you've ever seen the CRT source that's legally distributed with the Windows SDK.)
I don't think Microsoft cares that much, but I'm sure they view it for what it is: illegal, unauthorized usage of their intellectual property. (I'll hold off on my personal views of 'intellectual property' and whatnot; I'm not a lawyer, and those opinions are hardly relevant to the reality here.)
Still, even if Microsoft doesn't care, Wine Project and ReactOS care. My employer might care. There are unfortunately legal implications that exist, and if people want to play by the books they have to at least do the basic due diligence.
If you genuinely just don't care, you can lie to them and claim you never saw the original code, and attempt to cloak any code theft to make it indistinguishable from clean-room reverse engineering. Nothing stops you from doing that. Hell, the trouble is that it really can't be proven for sure. Even holding the positions I do on forums wouldn't prove my own innocence in such a situation, though maybe it helps build a case.
What stops someone from viewing that repo over Tor, on a different git server, or at a public library, unsecured WiFi network, etc and being considered tainted? At what point is someone considered untainted?
This seems like a grey area that slows the pace of R&D in countries that believe code is copyrightable & patentable (the US and select Western countries) compared to say New Zealand & China, where these aren't an issue.
Where did you get that idea about New Zealand copyright? Code is copyrightable here, see e.g. [1] or [2].
And it's not about belief, but definition. Copyright and patents are human inventions defined by countries' laws (which is why different countries have different rules: different definitions). In NZ, as in many countries, "Computer software follows the rules for literary work" ([2] again).
It was more that we clarified what was and wasn't patentable, as I don't think software was exactly patentable before that either; its patentability and the ability to enforce said patents were ambiguous. Patents on software are not quite completely banned, either, as, from your link's linked source, "Processes will still be patentable if the computer program is merely a way of implementing a patentable process."
I tried googling for KiInitializeContextThread and there are lot of search results for this name. For example, a presentation in Chinese dated 2005 year described process creating and mentions this function: [1]
The sequence of events that happens inside KeInitThread() can be obtained from reverse engineering. If you compare the code of this function in WRK [2] and in Reactos [3] code, you'll see that while they do similar things, the code is not the same.
Regarding NpxFrame, I don't know why this name is used in KiExitV86Mode, but if you compare functions KiInitializeContextThread in WRK and in Reactos, you'll see that in WRK the variable is named NpxFrame [4], and in Reactos a similar variable is named FxSaveArea (which matches structure FX_SAVE_AREA). The variable named NpxFrame in Reactos is used in other function, KiExitV86Mode.
I'm confused about those examples. Both symbols seem to be referenced in quite a few web resources that aren't dumps of that research kernel and either github search is a bit broken or I can't seem to find many of those in your [1] repository.
Nothing really these days. It was a thicknet (10BASE5) LAN similar to PUP with service names (strings) rather than port numbers. We used it at MIT pretty much only inbetween the AI and LCS machines (which were all in the same machine room and building) but was never really commercialized except that early machines from Symbolics and LMI were just CADRs which had chaosnet interfaces in them so if you had any of those early lispms you needed chaosnet to talk to them.
There were other experimental LAN systems around as well, some commercial some not.
It was all superseded in the mid-late 80s by IEEE ethernet.
It's a little bit of a nostalgia trip for me but if you never used it there's not much to learn in retrospect.
It was used way beyond the 9th floor of 545 Tech Square. To the west, the longest cable run was to the NW16 Plasma Science and Fusion Center, I think there were only 2 taps on that cable, it was marginal. To the far south the Mathematics Department in Building 2, and it went east to Building 20 at minimum.
I actually implemented something on an embedded linux product once: a busybox initramfs that you could boot into "recovery mode," then along with dropbear, SSH into a completely in-memory system and re-flash the entire system image without having to pop out an SD card or connect a cable for DFU.
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!
I've implemented something very similar for upgrading headless Linux mobile robots. One nice property of this approach is that the in-memory installer environment and associated scripts can be common between USB-based install media and a remotely-triggerable kexec type installer.
At first, it surprised me there wasn't more standard tooling out there for this kind of thing, but as I got more into it, I realised how specific to our particular needs my solution had become, and I could see how it would be hard to offer something generic that would be a good fit for a wide range of use-cases without being super-bloated.
The issue becomes when you're calling some generic library that's unaware that it is running in a request handler. If you want to log from deeper in some logic, maybe you've passed some data or domain objects but not a request/context/session object. Do you pollute that logic with additional data passed in or does your library just create its own logger and call `log.info('intermediate result of some thing: XXX')` and let the CLS magic associate that with the request that generated the call?
And generally speaking, you want to exit the domain of request/response as early as you can, because it's your interface with the outside world, rather than something that should be pervasive throughout your system.
