Re: Timestamps!
If FreeBSD has a 'one true source' repository then it's hard to see how git is a good fit for accessing it. It's designed for, say, Linux, which has 15,000 true source repos.
459 publicly visible posts • joined 2 Jun 2008
Biobank signed contracts with 3 Chinese research institutions, who then duly ignored the contract, and tried to sell the data on. Not exactly jaw-dropping.
Biobank claims that the data contains nothing personally identifiable, including addresses and DOBs. That claim needs to be taken with a liberal quantity of salt. Back when I was in NHS data 'socioeconomic status' actually meant a postcode, which you could run through another database to get the socioeconomic status. The DB probably also contains a real DOB, to allow the scammer researcher to get the current age, rather than the age when the participant signed up.
Also, it's hardly been rotting for2030 years, the language has been improved greatly.
Well, that's a major part of the problem, isn't it. Years ago I had to dump Joomla and move on to WordPress when PHP moved on from v5, which was a major PITA. It was literally easier to learn a completely different CMS when Centos dropped support for PHP 5. Each new release causes problems. Which is hardly surprising when you consider that the language started life as a bunch of simple CGI binaries in C, and gradually evolved as stuff was added. That's no way to create a programming language.
Backdoor suitability - I think you've got this the wrong way round. Debian would be a bad choice, because of the two-year release cycle. The same is true of Ubuntu, since most (apparently 95%) of users are on LTS releases. Arch is a rolling-release distro, so downloads include the most recent version of everything. This makes it more susceptible to hacks such as the XZ Utils backdoor.
Why anyone would want to target Arch users beats me, though.
The fake CAPTCHA tells them to hit the Windows/Super key and R, then Control and V followed by Enter – a combination which, any reader who's used a computer for more than a week or so will likely recognize, opens up the Windows Run prompt, pastes whatever the attacker placed in the clipboard, and executes it.
I've used a computer for more than a week - 48 years, actually. I had literally no idea that "Windows/Super key and R" opened up a "Windows Run prompt". Looks like I've learnt something useful today.
So... how many of you actually think that it's a good idea to hand over all your passwords to some arbitrary third party? Seriously? Single point of failure, anyone?
If you're confused, you could try your government's "Top tips for staying secure online", which is, in my case, Viz the National Cyber Security Centre: "A password manager stores passwords safely for you". There, it's official.
Constantly forking distros...
I had to evaluate a significant number of minor distros recently to come up with a low-footprint live system. The conclusion I came to was that many of them were the output of a small number of highly opinionated individuals (or one person, actually), and that "highly opinionated" generally means, well, wrong. And that many distros were effectively dead, and had been for years. All those lists of distros you find are very misleading.
At the end of the day, there are only two realistic options, with minor variations on those two, because (a) they pay their developers, and (b) they release frequent security updates. For all intents and purposes, the OS actually is standardised. Whether you can live with that standardisation is another matter, though.
The threat to cryptography from future large-scale, fault-tolerant quantum computers is now well understood.
I love it. And here was me thinking that the actual threat to CNI was some dork leaving their net-connected RPi in my local electricity substation. Or Cisco. Or everyone putting their bank logins on their mobile phones. Or whatever.
I have a family member who's being treated in a Spanish hospital for cancer. His Spanish isn't great, and he's not remotely medical, so he runs all his reports and letters through the free Grok.
The output makes my head spin; it's incredibly helpful. It's rational and well thought out. It correctly summarises the current situation, and provides advice on future treatment options, what he should be doing now, what more he should be telling the medics, and more. My wife's a GP and she's astonished by it.
I thought the whole "AI" thing was a pile of crock until I saw these reports. Don't ask stupid questions, and you might actually get something useful out of it.
A certificate does not prove that you own anything.
When you request a certificate for a domain Let's Encrypt verifies that you control that domain. Specifically, it uses ACME to contact the domain and confirm that you have placed a secret on the endpoint. The intention is to establish "proof" of "ownership". If it didn't establish that, then I could just just get a certificate for my local bank and take all their money.
Neither the article nor the Let's Encrypt link give any realistic reasons for needing a cert for an IP address, so what is this actually about? What's the use case?
A cert proves that you own the resource, and enables encryption. But how do you prove that you own an IP address? The vast majority of users are just borrowing one from someone else who leased it. If I create a server somewhere, get a cert for the IP address, and then delete the server, there are probably going to be 5 days where I have a cert for somebody else's new server.
And you don't need a TLS certificate to enable encryption anyway.
Is this actually for sites which can't get a domain name because the name would be seized by a govt agency? Certificates for the dark web?
I've done a server which required users to log in (because all the pages were user-specific, so the server needed to know who the user was) without cookies.
Since HTTP is stateless, the client has to send something in the request to identify themselves. No cookies in this case, so the server generated an encrypted session token that was just passed backwards and forwards between the client and the server. I guess this is what you mean by "JavaScript".
Both mechanisms are equally secure, because the site is HTTPS-only. The token has the advantage of ensuring zero persistence; it's gone if the browser tab is closed. If you actually want persistence, so that the user can connect on the next day without a sign in, you'd have to store the token on client storage. IOW, it's magically become a persistent cookie.
You can't expect a user to re-authenticate, MFA or otherwise, every time they visit a different page. Since HTTP is stateless, the user must instead send some form of identification to the server with every HTTP request. One way to do that is to send a cookie. IOW, the whole point is to bypass MFA, or simple password entry, or whatever.
Ubuntu 24.04 serverBirth: 2011-07-19
Well... that's the problem with 'birth', isn't it? You're running a distro which was released 13 months ago but the root directory was created 14 years ago. In those 14 years your computer has probably been power-cycled, restarted, and crashed a zillion times. You've probably even replaced the drive with an SSD and kept the same birth date. So the birth date isn't really of much value.
And loads of people in the other comments seem to be confusing it with uptime. I used to think I was doing well with an uptime of a couple of years, but nowadays I'm getting 2 or 3 weeks with security update restarts.
I am distrustful of AI but have been keeping an eye on Google's AI Overviews as I encounter them and was slowly being suckered into thinking it's not as bad as I had believed
I occasionally ask Physics questions, and I recently asked one about the meaning of a failure in a specific theorem (Bell's inequality). It gave a plausible summary, and then produced exactly the wrong conclusion. I think it got confused about the meaning of what was basically a double negative : a failure of an inequality. It had a choice of two answers, and picked the wrong one.
OTOH, I'm constantly typing in simple questions about software packages ("how do I generate an email invoice in Stripe" yesterday, and similar), and Google always chimes in with its own answer. And, most, of the time, they're so accurate that it makes my head spin. That particular one wasn't quite right because the software has changed since the AI learnt the answer, but it was a good start. You still have to read the proper hits, but I'm coming to the conclusion that the AI is actually very good with this sort of simple question, and undoubtedly better than most of the slop you find on the net.
"One of the things that we've noted is that you'll have a person in Poland applying with a very complicated name," he recounted, "and then when you get them on Zoom calls it's a military age male Asian who can't pronounce it."
I'm not quite sure how y'all gonna manage with this one. Many of us over here will still remember a famous Polish trade unionist who was apparently named "Lurch Wallesa".
MS want to be the only ones in town providing shitty AI code helpers (and not inconsequentially sucking up all your code to feed into its LLMs)
Ok... so now we know why it's a 'shitty AI code helper'. Second-rate devs feed their second-rate code into the LLM. Crap in, crap out. Karma.
The problem isn't that it "writes log entries as root by default" (anyone can write system log entries without being root); the problem is that it (a) runs as root, and (b) someone has been sloppy about munmap'ping null pointers. This shouldn't really be a problem, but the concern is that another program, which is not running as root, might somehow be able to take advantage of this, and get atop to run something on its behalf, in which case non-root program #2 owns the box.
The moral is that if you've got something you don't know about running in the background, and that program is running as root, and you have concerns about the code quality, then you should stop running that program. Seems fair, and RTFM doesn't really help in this case.
Oh, wait. It's just occurred to me that every time I run Task Manager I see hundreds of these things. Damn.
You're not going to like this. My Brother MFC is on the pseudo-DMZ (between the office firewall and the router firewall), and calls home, and updates itself, constantly.
Every 3 months I get invoiced - 1.9p (UK pence) mono, 12.4p colour. The toner turns up automatically in the post when it's low.
Why? Because I've spent 25-odd years buying lasers and laboriously calculating cost-per-page, and most of the time the cost was way above this (sometimes 18-20p). Life is way too short to be worrying about whether your toner is good enough, whether Brother's updating your firmware, sourcing another toner supplier, placing orders, counting pages, whatever. I've got better things to do. Not right now, obviously.
How do you distribute the one-time pad to whoever is supposed to get the message?
Quantum Crypto. That's pretty much the whole point of it; low-speed links are used for distributing keys, higher-speed ones for OTPs. Not a huge uptake, but BT has been running trials for years.
[note that this is entirely unrelated to post-Quantum Crypto, which has been in the news recently].
"The monitors at HUD are now showcasing the wins of the Trump administration," a spokesperson told The Register, "including action to lower the cost and expand the supply of affordable housing. We expect the media to cover these historic achievements with the same level of detail and immediacy as other frivolous stories."
I love it. Either this guy is a complete moron, or an evil genius.
Once upon a time, microcode was quite the fashion.
Pretty much everything was microcoded and bit-slice back in the 70s. I've just dug out my Varian 72 System Handbook (dated March 74; my first job in the 80s was working on a V72), and it had an option for a 'Writeable Control Store' (we didn't have one). The V72 instruction set was in the readable control store; if you had a writeable one you could write your own microcode to extend the instruction set.
I did a bit-slice processor in the mid-80s and wrote all the microcode for it, but that was about the time when custom silicon was becoming relatively cheap, so microcoding largely died out. Fast forward 10 years, though, and it was back in fashion, because it was too difficult to verify complex processors.
Microcode probably can't do that, such low level things like the add instruction are hardcoded.
Half right. Data-related microcode basically enables and configures connections between function units and to/from memory, loops when necessary, and so on, and the ALU/adder itself is "hard coded". However, you could decode a simple ADD instruction, for example, into two or more operations, and simply increment the result (I've done a lot of microcode for a (graphics) CPU, where a single blit/fill/draw/whatever instruction could turn into hundreds of operations).
You've missed the point. If you put the wrong numbers into the page table then it's game over.
I've done one device driver, which DMA'ed from hardware direct into user space. And, believe me, there are many, many ways you can fuck up without ever seeing a pointer. Rust would have exactly the same problem.
This may be a novel idea (spoiler alert, it isn't) but how about a search engine that just takes search terms with the usual operators of and, or and not, and gives the results that fit including the null result if nothing fits. Just like Altavista used to AFAICR.
Google did that for years. It was a long time ago, but I think that may have been one of the main reasons I switched from Altavista.
Anyway, they dropped it after a few years, at about the same time that they screwed over Usenet. It was a disaster for techies who had to do detailed textual searches for programming problems. The current syntax may have made them a lot of money, but it certainly did me no favours.
You don't need access to anything which is potentially encrypted. You interfere with the radio signals from the GPS satellites; either jam them or, if you're very clever, provide your own local ones. It's well-known that the Russians already jam GPS over the Baltic/Black Sea/Eastern Med/etc. It's hard to see how anyone in or around the Ukrainian border could get a GPS fix.
Not so sure about that. The Starlink satellites are travelling at about 17,000 mph. The drones are travelling at maybe 1% of that speed, in an arbitrary direction relative to the satellite it's currently talking to. Determining whether or not it's "moving at high speed" is non-trivial, and there's probably no engineering or commercial justification to even try it.
I don't know anything about Starlink but, even if the terminals have GPS receivers in them and transmit their position to the satellite, it would be trivial to forge that position. The Russians do that on a daily basis; just ask anyone travelling near Kaliningrad, for example.
I ran a small department in 83/84 that got CP/M running on my own Z80 hardware. It was a fantastic buzz when we got WordStar up (not to mention C and Fortran compilers). It really did feel like the world had changed at the time. IBM eventually screwed us, of course, because people still remembered who they were back then.
I've done a huge amount of hardware since then, from bit-slice to ASIC to quantum, but nothing really compared with that.
So who is "whoever"?.Is it the EU who demanded that MS keep the market open? Is it Crowdstrike who insusted that their product should include such drivers, but who clearly didn't fuzz test the data input? Is it the customer who chose MS and CS as their "joint" system vendors?
I'd have thought that's obvious. It's the customer, for not carrying out the due diligence to determine that their mission-critical system relied on a pile of amateur-level crock supplied by MS and CS. All this after-the-fact whining is just infantile.
And MS's attempt to pass the blame on to the EU is equally infantile. All the APIs in, for example, the Linux kernel are published. This doesn't make anything insecure. Security is an end-to-end process, and that process failed spectacularly here.
Burnt out in one specific area of the chip
This. The article pretty much confirms that this is the issue with the Intel chips when it says that the eventual failure rate is 100%; failures increase over time. The 4KW thing is a red herring. The actual die power consumption is a function of the frequency, voltage, and capacitance driven; chips like these are very carefully designed to power up specific sections only when required, and to limit the frequency and voltage to keep the die temperature to an acceptable level. The problem is that the tools which predict temperature distribution across the die are not very good, and you can never be sure whether or not the MB has adequate heatsinks, and you can never be entirely sure when silicon on a new process will fail. Eventually, some part of the chip will pop, unless you're very conservative. Microcode is going to be a very blunt instrument for controlling this.
Two of my VPS providers (FastHosts/Ionos) are doing exactly that right now. And it looks like exactly what I need - one of them tells me they'll be able to support full-custom images after the transition.
The statement "Migrating to new hypervisors – which Gartner terms "revirtualization" or virtual to virtual migration – is rated a tech that has reached peak hype as it is applicable to between five and twenty percent of organizations is simply peak bollocks. I dumped bare metal 5 years ago because VPS was way more cost-effective for me, and still is, as long as you don't do anything stupid like paying Broadcom.
Err … yes you do.https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/
It’s also a huge breach of UK/EU GDPR.
Err.. I think you might you have misundertstood. This is a tinpot information broker in Florida. It should be pretty obvious that there's nothing in US law that requires information brokers to find the country of origin of their data subjects, and then trawl through the laws of that country, and then decide whether or not they're bound by those laws. Because, of course, they're not. It should also be pretty obvious that GDPR is only relevant in very specific circumstances and places.
My first dev machine in my current employment (~1990/1) was a SPARC box, with a DAT drive. I've still got the tapes, but it would cost more than I've got to get any data off them. And the data has exactly zero value anyway. Still, it would be interesting - I've backed up stuff on USB sticks that was unreadable after 2 years.
Nowadays you'd use something lighter weight such as containers, etc.
I'm getting the impression that there are a lot of instances out there which are a single containerised app, running on an entire VM. So, basically, you start with 100 VMs, some dev decides it's too complicated to get the app running on "bare metal", so they dockerise/whatever it, then place that on the VM instead.