Re: Really?
The whole point of SEV is to defend against an untrustworthy host (either because its owner is evil, or his organization has been penetrated by some three-letter agency). So it should resist also physical attacks.
1981 publicly visible posts • joined 18 May 2007
As expected, Apple comes out looking bad in this, and I am pretty sure they knew it ahead of time. This means there must be mighty arm twisting going on behind the scenes. Speculating Apple has been told by U.S gov in no uncertain terms to do something about child abuse pics, with the threat of legislation to force mandatory backdoors, if they do not comply.
Python and Perl have different goals and design philosophies.
Perl as it is is more useful in many cases than Python: You don't wear down you fingers into stumps writing it, and you don't have to import lots of libraries to perform common tasks. It is the ideal language when your program massages text, files and processes, and is not too complicated to fit into one source file of reasonable size.
Python is certainly better for larger applications.
I have been the web interface of Teams on Linux all through the pandemic. Works (even camera). There is supposedly a Linux Teams version, which is essentially a web browser running a single app (an Electron monstrosity), and some of my colleagues who have tried seem to have trouble with authentication all the time with it, so I never bothered. Web Teams works for my needs.
My spouse has tried to work with Teams on Windows, with scarcely less problems (and as the IT support of our house, these immediately are my problems, causing grey hair). Yes, it really has trouble comprehending a user may have to access Teams as a member of different organizations, or as a "consumer" Windows ID user. How can it be so hard?
The problem with ReactOS is it is chasing a fast-moving target, Windows is whatever MS says it is, and nobody will use a Windows clone that does not run recent Windows software. Linux started out as a Unix clone, but that was a much simpler and stabler target, and nowadays some OS'es (even Windows) are trying to provide Linux compatibility, instead of the other way round...
True, but the bank will nevertheless forcibly open the box in certain circumstances. For example, if the police turns up with a warrant for a particular box, the bank has reason to believe the box contains something hazardous, or the customer stops paying rent and cannot be contacted (the terms of my bank say they will wait for a year in that case, but then they will open it).
I actually used White Box Linux when I needed a RHEL clone, but it was a one-man band (or nearly), so after a year or two its maintainer gave up, and recommended CentOS, to which I moved.
Scientific Linux was a bit different, it survived until fairly recently, and the reason is it was not just a RHEL clone, but bundled software that RHEL did not have (I think OpenAFS support was one notable addition).
> Thing is Betamax was/is way better than VHS
A beloved tech myth. Actually there was very little difference. Both improved with time, but VHS obviously had more time to improve. "Late" VHS was certainly better than early Betamax was.
I used to have also a S-VHS deck, a backward-compatible extension that required slightly different tape (it could also play back and record regular VHS). THAT was a clearly visible improvement, almost DVD-quality. The fact it did not take off shows VHS was good enough for most people.
Helsinki schools had gone to Office365, but that is pretty usable via web. My kid did pandemic home school with it and with some school website from Google (forget the name right now). Assignments were submitted that way. Chromebooks would have worked just as well (although he did already have a PC), no Windows stuff was actually installed.
> That said is someone fitting 3rd rail to the highland lines? I have seen the pictures of the Southern region electrics there.
The Swiss solution. I recall decades ago traveling there by Interrail and they seemed to have everything, even narrow-gauge trains electrified. Some had 3rd rails, particularly those going up mountain sides, some a bit flimsy-looking overhead lines.
Or run on battery packs. In the case of trains, it would be straightforward, since weight is not as big an issue as in cars, and the battery pack could be quickly swapped with a recharged one at stations, so would not even have to last the entire journey.
The problem with hydrogen for energy storage is the process of making and using it is not too efficient.
> I'm making the big assumption here that the digital coins they wish to introduce will not be mineable per se?
I would say that is a safe assumption. The Chinese Governement will only tolerate digital coins whose supply they can control, the same way as that of ordinary money.
The planet thanks the banning of mining!
XFCE for me too. Desktop managers are just a tool to launch and manage apps, not an end in themselves.
Having loved it for years, I can say there are some places, where the usability of XFCE could be improved (like adding an app launcher to panel could be simpler), but these are minor niggles. Could probably be fixes without adding bloat, though.
Yes, reportedly a security researcher had actually already found earlier this year that ANOM is broken and BCC:s everything, although he did not know law enforcement was using the backdoor. His pages about it got taken down quickly... This must have been one sign that the secret could not be maintained much longer.
Just bury them deep into stable rock.
No need for a religion: If technical knowledge is not lost, people will know about the site and its dangers, and will not go digging. If we get the "A Canticle for Leibowitz" scenario (new dark ages), people will not even be able to dig there, until enough technology is rediscovered. At which point they will know about radioactivity (or will learn pretty soon), hopefully also have deciphered old scriptures describing waste repositories.
Of course geological processes can also bring the waste up, but with careful design and site selection, it can be ensured this is not likely to happen before the waste has decayed to safe levels of radioactivity.
> Germany is decomissioning all atomic power plants,
One of the most disastrous decisions for environment, ever (after the introduction of leaded gazoline).
Germany is one of those countries that could run nuclear power plants safely, and they are much better for climate than coal or natural gas (the use of which is increasing in Germany as a result of this stupid decision).
From the article: "In 1996, Conner Peripherals was acquired by Seagate."
Maybe the multi-head ideas came from there. Or at least the related patents, so they don't have to worry about some troll coming after them because someone had patented the obvious idea of speeding up drives with multiple heads.
True, looks like it is:
https://www.audacityteam.org/copyright/ "The name “Audacity” is a registered trademark."
So any fork has to find a different name. Same thing as LibreOffice is now the name of the OpenOffice fork (OpenOffice being nearly a dead project, but still clings on to the trademark).
> GPL doesn't prohibit the sale of GPL'd software though. [...]
True, and that is much how many open source companies work, although the value they provide is support. "Make a deal with us, then we provided copies of the software and respond to your support tickets".
What you cannot do is sell a copy of GPL'd software and also prohibit resale, or giving it away, or add any other restrictions. You also must commit to providing the source code for the software in usable form. (Not on paper or clay tablets).
> It sounds to me like this move is to create a clearer chain of responsibility. I may be daft and naive though.
No. The aim is to increase ownership, not responsibility. The company wants to be able to relicense new versions of Audacity on different terms than GPL.
Fork time.
> and application programming interfaces (APIs) on
Again. I have seen innumerable announcements and other texts, where the abbreviation API is defined in precisely this way, and never used again in the text. Besides, by now everyone knows what it stands for.
Sort of obligatory shibboleth to mention it.
The 64-bit version of x86 actually has twice as many general-purpose registers as the PDP-11.
In any case, the number of CPU registers is irrelevant for any language that works at higher level than macro assembler. Don't be misled by the "register" keyword in C. Modern C compilers actually ignore it, except for enforcing the restriction that you cannot take the address of a "register" variable, and it never was more than a hint to the compiler that it should give some priority for optimizing this variable.
Disagree, sorry. At the hardware level, all integers are unsigned. CPU:s do provide support for interpreting them as signed when needed, with features like the overflow flag and sign-extending instructions. Programming languages of course may support both signed an unsigned integers, with the compiler imposing the appropriate interpretation.
malloc() argument and size_t are naturally unsigned, because a negative memory allocation size makes no sense, and a signed argument might not be able to specify the largest possible allocations. Not so relevant in the 64-bit world, but in the 16 and 32 bit CPU:s you could actually want to specify malloc arguments that exceed the largest signed 16 or 32 bit integer.