Posts by that one in the corner 5492 publicly visible posts • joined 9 Nov 2021
> "Oh, but why don't they just host their project on github!"
Microsoft just *love* people who complain like that!
> Some would rather host their projects themselves
Or even just use another third-party project hosting site.
Come on World, what is wrong with you, *every* project should be on Github! What Is Good For Microsoft Is Good For America etc etc.
The 100s of architectures refers to the ffmpeg builds, not specifically GMP.
It *may* be the case that the only reason ffmpeg "needs" to be rebuilt for each architecture is only because that allows the GMP build to optimise itself, but that seems unlikely. From GMP's point of view, many of these "architectures" may well be the same, just some other part of ffmpeg wants to know the difference (e.g. forget about x86 variants, where does this OS variant store this file?).
> In many CI setups caching is standard and, indeed pretty much a requirement for anything using images from Docker hub. GitHub doesn't seem to have this and it also doesn't seem to have any kind of rate limiting
True about the lack of rate limiting.
But whether or not Github provides caching would not be relevant in this case - if you read the (even updated) build script that the article points at, the guy was explicitly deleting files and then fetching them again using a command line Mercurial client, which he replaced with explicit use of a wget to an FTP site. Those would bypass any Github caching.
He was managing to run a Mercurial client to get the sources, which rather implies he could have been using it properly (just checking for updates instead of explicitly chucking away the local copy every time the build run). Even pushed from his local copy into a git repo and made the script use that (hence all the copies of the script...).
Saying "Github doesn't do Mercurial" - well, it is true that Github doesn't provide all the tools to work with a Mercurial repo in the same way as it does a git repo, but this guy already knows enough to use a command line Mercurial client to pull the library down, it can't be beyond him to add in use of the git command line tools as well.
> maintaining an attractive nuisance
Loving your characterisation of Github users as having the awareness of seven year olds. That does strike at the heart of the problem for this ffmpeg builds guy (including his response of "you should change the cron timings".
> I would frequently come back to a project from 6 months ago a
There is a teeny, tiny, itty bitty difference between cleaning out every six months and starting from scratch every time a batch file enters a loop to trigger another build.
And complain to whoever wrote the stuff that is changing the environment (or requires you to change it) in a way that can affect another project: that is just bad work on their part. You really should not need to have to resort to Docker or VMs or anything else to keep a working environment. I know a lot of projects piddle about like that, but maybe we can get them to grow up one day.
Why are builds like this continually grabbing from *any* server?
> This build was configured to run parallel simultaneous tests on 100 different types of computers/architectures
And all of these architectures need their own copy of the GMP code? Sure they aren't just using the same sources with the usual flurry of #ifdef's?
For that matter, what about the rest of the ffmpeg and dependencies source code? Are these being grabbed afresh for every single architecture? That certainly seems appears to be the case, if I'm reading the updated script correctly[1].
The DDOS aspect not only appears to be built in, but why aren't all these copycat builders pointing out that it is wasting *their* resources as well (time, bandwidth and electricity)?[2]
[1] and the author of that update wants to have a careful think - any guesses whether running a fetch from *any* version control server - in this case, a Mercury server - is going to more costly for both ends than a wget of a single tarball from an FTP server? Or could a version control client perhaps pull down *just* recent changes - oops, no, we deleted the local copy, can't do that!
[2] oh, it is just Github's bandwidth and electricity? Well, waste away!
When has he ever hit one of his own announced timescales?
"By the end of 2023 you will be able to buy a ticket for this match!"
"We expect to be able to land not one, but two, tickets by third quarter 2026"
"It will be financially irresponsible not to own one of the tickets in 2036"
...
"Speak up! Tickets? Fight? We did that last Thursday, didn't we? Who are you?"
> I, for one, am not going to bother learning Red Hat specific stuff
> I know that some software vendors insist on a particular OS, but we can now say "no, that's not going in our network" - they can either lose a sale or agree to installing it on another OS.
Absolutely, go for it.
RH isn't breaking GPL but that does *not* mean we have to like them and continue to buy from them.
>> Gpl2 has nothing to say about programs other than the one you received. It does not refer to , or claim mastery over different programs (which would be absurd).
> But it does say about the distribution of the source code to that program, and the rights you were given to use that source code.
Be careful with the word "that".
Try phrasing it as (very clunkily):
> But it does say about the distribution of the source code to [the copy you already have of the] program, and the rights you were given to use that source code [matching the copy you already have].
Otherwise we could misread your "that" to be referring to the "future versions", which I'm sure you never intended us to do.
Now, you have full control over the copy you already have and nobody can take that away from you, nor is anybody trying to take that away from you.
But unless you have a contract, totally separate from the GPL, you can not coerce RH into giving you a coy of an executable, let alone sources, for any *future* version.
> how can RH do this and not have invalidated their licence to huge chunks of their distribution?
Go back over the sections you have quoted. If you have a copy of executables for v1.2 then you have the right to get a copy of the sources for v1.2[1]. GPL satisfied.
Nowhere does it say that RH is then required to supply you with executables for v1.3; even if RH create v1.3 by modifying the GPLed sources for v1.2, until you get a copy of the 1.3 executable from RH they do not need to let you have the 1.3 sources.
And if you no longer have a subscription to RHEL there is no requirement for RH to supply the executables of v1.3 to you.
RH have changed the pricing and are not making friends, but their product (the subscription, that is), their pricing. If enough customers stop paying then RH may change their minds (or not) but inaccurate arguments about licensing help nobody.
[1] but only of the GPLed bits and any scripts needed to build them - you don't have a right to, say, a free copy of the compiler used to make the executable - I can send you all the bits for a GPLed Windows executable that I built with VC6.. Nor do you any rights to sources from RH for non-copyleft programs, whether you have the executables or not.
> if it modifies the code the resulting derivative is still covered by GPL, must provide the modified code if required and should not add further restrictions.
True.
And the definition of "if required" by GPL is if you have a copy of the executable of their modified form. Which you don't because you lost the subscription and RH never sent you a copy of those executables.
What RH has done isn't making them any friends but it also isn't breaching GPL.
> The question here is whether the business relationship under which RH provide GPLed code implying such a restriction on their customers.
It doesn't restrict what you do with the copy you already have, do the GPL terms are satisfied.
It does restrict whether RH wants to let you have a copy of the *next* release - which is nothing to do with the GPL, it is entirely about business relationships.
> I'm not a lawyer but as I read it the GPL requires you not to place any restrictions on the right to further distribute the source code.
They don't. You have the sources to v1.2, go right ahead and distribute them
RH will then choose to not send you the executables for v1.3 - as is their right - and without those executables you don't have a right to get the sources for v1.3 from RH. The End.
But you still have v1.2, executables and sources, and can distribute it at will.
BTW if you didn't get your copy of the v1.2 executables direct from RH then they have no liability to provide you with the sources.
> GPL licences, etc. need to be amended to stop future foul play
So the licences need to say that if you managed to get a copy of version 1.2 of a program from a specific supplier, that supplier is then bound to give you a copy of v1.3?
If you violate the RHEL subscription terms, you have decided to forego your copy of v1.3 - you still have v1.2 in all its glory.
What licence has ever said that you get the next version? If you want to say "GPL" then please quote the clause (you can easily get a copy to quote from): nope, it days that if you already have a copy of the v1.3 executable you can get the sources (for a reasonable fee - which can be via a subscription) but it doesn't say the vendor has to give you that executable in the first place.
Although I do agree that a court case would be good, as that does tend to make things clear to everyone (even if it also makes the lawyers fatter and more prone gout or diabetes).
> You don't have freedoms 2 or 3 because your subscription will be terminated if you exercise them.
Nonsense.
You have those freedoms and keep them forever.
If your subscription is terminated then you still have that version and can continue to use and distribute it at will.
What you lose when your subscription goes is the automatic provision of an updated copy from RHEL.
There is absolutely NOTHING in the GPL that gives you the right to receive any source code mods if you happen to gave an older copy of the sources or executable.
IF you get an executable THEN you the right to the GPLed sources.
BUT you voluntarily[1] gave up the subscription that would get you that executable. The End.
Your access to Freedom 0 is also almost totally unlimited: you are free to take a copy of a GPLed executable out of the RHEL distro and use it anywhere. The only way this is being limited is because you are voluntary choosing to run the *whole* RHEL distro, which is *not* under the GPL: the subscription management software and any number of non-GPL code.
You don't *want* to take the GPL exes out and try to use them without the entirety of the RHEL distro because that is too costly for your purposes. That is your choice to determine and has no bearing on whether you would be within your licenced rights to do so.
[1] yes, voluntarily: you knew you were breaking the subscription rules and chose to do so.
> I'm not letting anyone have them until I know all of my data has been permanently removed.
You aren't going to have a choice, eventually someone will get them off you (even if that is literally prising them from your cold, dead, hands - or just during the house clearance).
Perhaps you need a better approach than hoping some random commentard will come up with a sensible suggestion? And act upon it whilst you still have the faculties to do so.
Indeed - it doesn't matter if those are "percentages of all the employees are happy..." or are supposed to be "of the companies surveyed, this percentage said their employees were..."[1] it doesn't sound like many employees were "excited" to be in the office.[2]
[1] don't you just love stats reporting? Precise numbers, waffly descriptions.
[2] who is excited to get into the office? Is it Taco Tuesday? Actually, that *does* fit the figure quoted (with 7% left over for those who - are nipping into the supply cupboard with Brenda from Accounts?)
You are correct in your original thinking[1].
This claim of just dumping out copied text en masse keeps appearing: it seems to be very appealing to some (or maybe they just can't their heads around things like MCs in the first place?).
There are plenty of ways that you *could* get "accurate" personal data out, starting with pure chance: these models are being queried many, many times and someone who actually lives at 23 Railway Cuttings, East Cheam is one day going to see that appear in a response. Or maybe your personal info is actually spread around the Internet so much that the model has pushed the correlation of "Fred" followed by "Bloggs" followed by "Mastercard 1234 5678..." up to near certainty!
You can also get *inaccurate* personal data out: oh look, ChatGPT "claims" a radio show host is an embezzler. The LLM gets it in the neck both coming and going.
[1] Okay, the process is more involved than a Markov Chain (and a lot messier and less comprehensible - less explanatory power - but MCs are a good starting point)
Great. The *one* thing that is *required* to demonstrate that there is a claim for damages is replaced by page after page of "maybe". Do they *want* this case to fail?
You could almost imagine that these pseudonymous plaintiffs are really named " OpenAI" and "Microsoft".
> Providers of AI-driven solutions get the opportunity to test their products in real environments to assess if they meet the customer needs
Shouldn't the "solutions providers" have done that already? Verified against Requirements Specs and so on?
> TEFs support the new legislation, which called for regulatory sandboxes. Through rigorous testing, developers can ensure their technology is trustworthy and complies with laws so it can be deployed and made commercially available
Ok, that bit is more sensible - hopefully the TEFs do what all (good) test labs do and issue a certification (with the very carefully worded list of what tests performed and results obtained).
But possibly not a bottom line of "therefore this is safe to release" just in case it goes all Skynet after 18 months and they don't want to shoulder any part of the blame ('cos who can predict what it'll do with unpredictable User inputs?)
Targeted advertising - the only way to stay safe, to keep your privacy, is to be exactly the same as everyone else. Think the same, shop the same, browse the same and you can sink into invisibility, just one of the indistinguishable masses. Perfect fodder for the mercantile cannon of industries fighting for their rightful portion of your life: Welcome, my son, welcome to The Machine.
Or fire up your PiHole, cast Chrome to the wind, cry "For Harry" and delete cookies on exit. They may take our cycles with their outrageous scripts but they shall never have our Topics.
"Your model WILL do something unpredictable, and we can't predict when"
Not some wishy-washy line like:
> it's not outside the realm of possibility that they could act in ways that are difficult to predict.
As the ML these days is pretty much all based on neural nets[1] (including GANs) you'll end up with a magic box that is pretty much guaranteed to do something unpredictable[2]: why do you think we have so many cautionary tales about Djinn?
[1] is *anyone* doing anything different, like running any form of rule inference learning and generating explainable systems? Not that the created rules are guaranteed sane, but you can at least read them out during the court trial.
[2] are you absolutely sure your training and data conditioning will ensure the model will never see an input out of its expected range? It's not like feeding numbers into a simple equation, a model can go totally Bursar on you. Look up "glitch tokens", especially if you are offering a cheap and quick - sorry, "affordable" - model-building service ("save money by not starting totally from scratch this time").
Kodak PhotoCD, launched just before Win 3.1 IIRC
Take your photos/prints down to the local copyshop/film developer - or be really sure that you wanted to share all the shots on a new roll of film and tick the box on the yellow envelope that came with the film. Postal orders or cheques enclosed for payment or write your account number in the space provided.
The whitepaper includes some interesting statements, examples include (annoyingly, can't copy'n'paste direct quotes from the PDF on this device to give the full effect):
Pointing out that there will have to be a way to verify the logic in the code of a "smart contract"; this can not possibly make the system expensive to use, as we all know that automated code proofs are easily available and, if not, human programmers can do code checks for barely over the minimum wage. (/s - superfluous, but may help if someone really is holding up the "will review code for food" cardboard sign).
They point out that credit cards exist, but apparently they will only protect the supplier of the goods, not the consumer. Um, I know making a chargeback can be a pain, but a CC giving *no* protections to the consumer when used for distance shopping? Clearly, the banks authoring the whitepaper know more than I, but... yikes?
PS
Haven't spotted any mention or reference to *how* the "smart" bit will be coded (if you have, please correct me) so looks like Javascript is still on the cards (well, it does make eating JSON data easier, what could possibly go wrong with an eval(readfile())?)
I read it as closer to putting a hold on the money whilst it is still at your bank (so no extra trusted third party) and transferred in payment when the conditions are met (delivery of goods); one also hopes that the conditions are also set to allow cancellation of the order and/or a maximum time for completion, after which the hold is released an you get control over the funds back.
This way, your bank gets all the transaction fees (including when the supplier calls to verify the hold is in place) nothing for that greedy escrow agent.
UNFORTUNATELY although the above fits the description given in the article and could actually be a useful addition to banking services, the actual whitepaper starts by prattling on about digital currencies and stablecoin, so it isn't going to be anything sensible and will probably end up with overly-complicated smart-contracts that are coded in Javascript and can be gamed in all sorts of fun ways. Hmm, if I can cause *this* "contract" to trigger now, which will trigger Fred's contract, but mine is so badly code (oops) that it garbage collects, meanwhile Fred's has completed and my other contract has swept in, got the funds, raised some interest, released it back to my first contract which is now ready to continue...
Also used work on Windows Embedded boxes that boot off CF cards (that kit is still in service and should have years left in its life - no, it isn't connected to the Internet).
At home, still have a perfectly functional CF bootable mini-ITX mainboard system, ready to be put back into service.
The problem nowadays is that IDE is only one of the modes that CF supports and the later cards stopped supplying it. So have gone from "any of the CF cards work to boot from" in the days of 512MB cards to "you suddenly pay a massive surcharge for a card that actually follows the whole spec" which made, say, a 4GB CF too costly to be worth it.
And three guesses whether an up to date copy of the OS that used to fit in 512MB will now even fit onto the 4GB card if I'd bought it! Annoying, as the 512MB card is in perfect nick (it only got read at boot, never written to during normal use). Ah well, at least SSDs are more affordable now than bootable CF cards.
Huh? Why do you want to remove that one?
> "display file icon on thumbnails,"
Ah, now it makes sense.
Remove those two and you'll never see icons for anything that can be thumbnailed so you won't spot the moment that Microsoft overrides your choice of image viewer. Again.
"IrfanView? Bleugh! You want a proper Microsoft Media Experience!"
> Right now, the only workarounds for stopping the high CPU utilization problem is either restarting the device or for the affected user to sign out. Locking Windows won't do the trick, Redmond wrote. The users must sign out.
So using Task Manager to kill File Manager has stopped working under Windows 11 as well?
And why would anyone expect locking Windows would help? Doesn't anybody else lock Windows when they go for a cuppa, fully expecting any tasks to continue?
(Disclaimer: zero practical experience using Win11; for all I know, TM has been neutered and locking now means deep sleep!)
> the alternative would be designing a milspec controller that ends up costing >$1m a unit and does the same thing
The story is that they *did* have a "milspec" controller supplied by the contractor, at an obscene cost, until a savvy submariner pointed out to the boss that it was actually just a video game controller (probably rebranded, that is what cost so much). Won't swear that they actually now use an XBox device.
The controller is only used for pointing the modern replacement for the periscope (and no doubt is not the *only* way of doing so - they may even still have those funky folding handles and can wear their caps backwards as a backup, before resorting to "ratings and binoculars").
(Tried to find my source to post the URL but search results are currently flooded with thr Titan story).
> He is able to beam himself at will
EM activates the teleportation by getting into the driver's seat, closing his eyes and meditating for five minutes: when he opens his eyes, ta-da they have arrived!
Meanwhile:
As soon as EM drifts off to sleep ("meditating") the *real* driver takes over (amazing what you can do with a Tesla paired to a bluetooth steering wheel from an old Wii game). When they arrive, all Tesla and SpaceX clocks are wound back to five minutes after they left (if it was only a two minute journey, they get wound forwards) and EM is gently prodded awake again.
This is how EM manages to do his amazingly long work days *and* explains why he is so happy to make those claims about "FSD is only 3 months away" or "you can buy a Semi with delivery in a year": he is getting lots of sleep and, according to his watch, it is currently an unseasonably warm February in 2017.
Don't worry about the employees: the worst they have to worry about is ignoring the factory wall clocks and being sure to have the company app running during meetings with the boss, showing EM time. Okay, there are a few odd days when they end up eating three breakfasts in one day full of meetings and they are super-careful around launch days (when they balance things out by having lots of two or three minute drives around the launch site for each fifteen minute drive from hotel to site).
Are there parts of RHEL that are *not* covered by the GPL and without which a fully RHEL compatible version is not possible?
They need not be major parts, in the grand scheme of things, but if there any little bits which may really be restricted by RH's actions that would be enough to prevent any rebuilds from being 100% bug-compatible with RHEL. A point which RH would be sure to emphasise.
If such a situation exists, *we* may all know that those components are irrelevant to 99.999% of Users, but even a few differences would be enough for RH sales & marketing to leverage into full-blown FUD ("you are unique, you are one of the 0.001%" would probably work on most CEOs).
All they have to do is set the perceptions about remixes they don't like, not the reality.
