Re: Wow
> (And you can't argue about the money going to the Military Industry Complex either)
Of course the National Parks money is going to the MIC - how else are they going to arm the bears?
5679 publicly visible posts • joined 9 Nov 2021
chromodynamics? That'd be Genesis 37:3 - and the quantum stuff is clearly the explanation for Genesis 37:5 to 7 and 37:9, whilst Genesis 37:29 illustrates tunneling.
We need NASA because all the muck we've been putting into the air is causing The Bowl Of The Firmament to become soiled - you can see the proof of this by looking at any so-called "Deep Sky" photograph. All those fuzzy things are obviously just muck (from chimneys of factories making the implants that go into vaccines), and smudges caused by all the rockets bouncing off (you can clearly see that rockets go up, then sideways as they hit, and finally down to the horizon, where they are dumped into the sea).
NASA must be repurposed to create a giant mop-on-an-extensible-pole that can be used to squeegee the Firmament and restore it to its pristine Glory.
After that, any leftover NASA rovers can be used to probe the Antartic Ice Wall. No, hang one, that would be silly. The rovers would only rust.
>> And, yet, those golfing trips...
> I know you think you are making a point there.
Well, one point being made is that you really are staggeringly incapable of looking things up on the Web:
Trump’s Florida golf weekends are costing taxpayers $18m, report says – as he hits the links again
The other point, of course, is that you see nothing at all wrong in Trump stealing millions of dollars from the tax payers.
>>>Are they? They are making cuts but the government is still there.
>> Except for education, science, health, veterans, environment
> Kids aint going to school? No science is being done? The hospitals have closed and doctors have vanished? There are no veterans left!? THE ENVIRONMENT HAS VANISHED?!?!?!?
Hmm, back a couple of responses and we see:
>>>> @that one in the corner ... you seem to struggle with simply reading the post
And yet, Trygve Henriksen clearly points out that the government departments dealing with "education, science, health, veterans, environment" are being gutted and you respond as though Trygve Henriksen said that those portions of the real-world have somehow disappeared! A quite staggeringly bad misreading.
> Kids aint going to school?
I certainly hope they still are (although it would not surprise me in the least to find that some schools been forced to end (some) classes) but the quality of the education (some of them receive, or will be able to receive in the near future) has gone down, due to the Trump's actions.
> No science is being done?
Less science is being done (or will be done, once the funds currently banked by the labs runs dry, as the replenishment has been halted)
> The hospitals have closed and doctors have vanished?
You seem to be unaware of what the DoH is concerned with, particularly in the heavily privatised US health economy, where the (vast majority) of hospitals and doctors are corporate. I know, you are used to the NHS, but the US system is different. You may wish to learn what governmental - well, most correctly, federal, instutions such as "the CDC" are and how they have been affected by Musk. And what the long-term affects of that are going to be, as the information the CDC would usually handle is no longer provided to the privatised sector.
> There are no veterans left!?
Of course there are veterans left, but the services they rely on are being damaged. Meaning that there may well be fewer veterans left in the not too distant future, compared to what there ought to be (see also health - and environment).
> THE ENVIRONMENT HAS VANISHED?!?!?!?
Whilst one might heartily wish that some small portions of The Environment would suddenly vanish and leave certain parties gasping in a vacuum, the physical environment is indeed still present (congratulations on noticing that, Gold Star), but important parts of the US government that investigate it have been shuttered, or are on their last legs (refer back to the points about "science being done").
One simple line from Trygve Henriksen, seven words, none of them overly sesquipedalian and yet you struggled. Sigh. And the chaos of exclamation and question marks really does help to highlight how egregiously you misunderstood.
We'll skip over, for now (unless you decide to bring it up) the little matter of the your response to Trygve Henriksen's second sentence, as we are all so aware of how much you wish you were an American stereotype and, with that aim, are practising (oh, sorry "practicing") the inability to comprehend sarcasm or irony.
> I am fairly sure he has difficulty reading based on previous interactions.
Oh come on, codejunky, you can do better than that!
There is a whole wealth of insults, both witty and vulgar, that you could fling to better affect; oh, if only you knew how to find them.
> I don't think you paid attention to the last sentence, the one about the debt.
Oh, I did.
It is simply that the effort being put into DOGE's games aren't doing anything substantial about the debt, going by what they find to boast about on doge.com, and the cost to repair the damage they are causing is going to drive the US into *real* debt, both nationally and internationally, in every currency.
I've been "enjoying" the discussions around ISO 8601 and how the effect it has when a zero is used to indicate "not (yet) known" can lead to Social Security records "showing" people to be approximately 150 years old - if you happen to be too computer illiterate to be trusted near a Tomy box.
The big picture of cyber security risks is important (well, duh) and the results of all these incompetencies are (going to be) devastating. It is also good, if we can, to dig into the extra tech details of where and how some of the other - problematic results - are being generated.
I swear that I tell Windows not to update until I say so. So last night a Windows box is left doing an overnight build, for the first time in an age, and - yup, this morning it is sitting there, job incomplete, console windows closed.
I know, my fault, you must always check the position of the stars (and other calendars) to see if this will be an inauspicious night to leave Windows unattended.
>> Burning these fuels, generates tons of extra CO2, which makes the heat-trapping blanket thicker and thicker, warming the planet.
"Blanket thicker" - this is also what we call an "analogy". "If the atmosphere was a blanket, that blanket is now thicker". There may - or may not - be a literal "thickening", or at least an increase in density[1] but that article is very much an introduction for the non-scientific (well, more for the not-yet-scientific-but-we-want-to-get-you-started).
Just in case anyone wants to try "you can't say on this page the atmosphere is getting warmer but then say here it is getting colder" I'll point you to the conspiracy that mass air movements are obviously not caused by localised pressure changes, that is just the story put about by Big Wind.
[1] 'cos CO2 biggerer than just O2! Duh!
> The problem doesn't seem to be a lack of solutions, but rather the opposite
You aren't kidding:
> Meanwhile, the portable UI community seem to be more interested in Avalonia.
ANOTHER one? I'd not even heard of "Avalonia" before today!
Mutter, mutter, why can't people all get behind one of the existing projects and complete the damn thing, as a portability platform, without spec creep and bloat, and without "oh, this is too old fashioned, so much easier to start again"?
>> the Javascript framework of the day.
Yeah, just like that.
.
> Frankly HTML+CSS+JS is a great choice for developing (eg) a forms-based UI, although like any software project it can be done badly.
A few years ago now, building an application which already had a C++ GUI, I found the HTMLayout library very useful for putting together additional sections, especially for built-in documentation and interactive help: a single source for those pages could be auto-massaged into web pages, printable PDFs and appear in the program, linked to what the user was actually doing at the moment. Before the days of (robust) embeddable JavaScript interpreters, btw. As that link shows, HTMLayout itself is not an active project and the author has a replacement, but it is curiously refreshing to still be able to see what *was* around, it is possible for people in the software industry not to suffer from amnesia for anything older than a few months!
At the time, this was the only HTML+CSS renderer that I could find (aside from a few rather twee projects) which would bind together with the main C++ code and run as a single process. Since then, I have done a few projects with a local-access-only web server built in, so the UI can be rendered using a standard browser, but I'm still interested in the single process option.
Although using the server+browser model does have big advantages, especially with respect to portability: it is a lot easier to write a UI-less server and build it on multiple platforms, then using whichever browser happens to be around.
How could that ever be considered safe?
Even just a simple up/down vote to "get the wisdom of the crowds" is open to misuse[1], let alone ingesting everyone's prompts and risking spitting back any part of them to another user.
It is almost as if the people making these systems have never realised why they are told to use their own logins and keep them private when using a shared website.
[1] although my attempts to train ChatGPT to answer everybody only in iambic pentameter are moving very slowly.
> But most people would like it to be more seamless and automatic if possible.
> they can #define things before the header is processed
Isn't that just a cae of copying the correct settings from the C portion of your Makefile/IDE settings across into the settings for your Rust portion? And after that it is just as automatic as you need as it is when building the C. The C/C++ toolchains aren't themselves magic - at best, they may provide a set of pre-defined macros (e.g. MYCOMPILER=1301 to identify the compiler family and version number). What these are can be found in the docs and/or by getting the compiler to dump them.
It is a bit irritating to dig out these definitions but it is a one-off - and only a very minor irritant compared to anything else when trying to get to grips with other differences in the actual languages.
> Anyone who's dealt with C libraries in a cross-platform situation knows how much of a massive pain in the ass this can all be even before you bring Rust into the equation.
I do a lot of cross-platform, and with multiple compilers on the platforms, builds - you just need a reasonably good build setup (I use Makefiles, with a half a dozen little utilities, so one build operation generates objects and executables for all the platforms in one go whilst I have a coffee). If you are at the stage where you are playing with combining Rust and C and you haven't bothered to find a half-decent build setup first[1] then you are just making a rod for your own back.[2]
[1] or, for some people, haven't bothered RTFMing about the IDE they are already using, mutter mutter!
[2] gawd, don't you hate a smug bastard!
Well, a C header file is just[1] a series of type and function declarations.
Responsibility for allocation and deallocation (aka ownership) only makes sense for instances of a type. As is shown in the Rust docs for Defining and Instantiating Structs: the struct is just a declaration and the allocations are made within the example functions they show, and ownership of the instance passes from variable to variable via the assignment/move operation.
[1] ok, there is no actual, solid, definition of what a "header" file is - some people call any old file that happens to be the target of a #include cpp statement "a header file" even though you can, of course, put absolutely anything you feel like into included files - just so long as the final compilation unit is syntactically ok. For example, something like the SQLite "bundle" C file can be created by #include'ing all the dot-c files one after another into a single compilation unit (which has its pros and cons) *or* you can just compile each dot-c on its own and pull it together in the link phase. So here I'll stick to a well-behaved header, and ignore that Naughty People can put all sorts of crap in there as well, such as putting in a line "static int fred" and causing every compilation unit to suddenly have an instance of "int" called "fred".
PS
Not that I'm actually suggesting that you *should* put cpp into Rust itself, just trying to point out that the argument presented about the macro language being typeless is a red-herring (and I forgot to mention that C/C++ gives you string typing and yet they are not bothered by the macro processor, because - that is a totally separate phase.
But if you have a utility for converting C headers into Rust, building cpp into that utility is - well, it is a necessity, the only way to actually make macro usage make sense.
>> Just the #define keyword is already problematic because its untyped and that would put a hole in the Rust type-system.
Huh?
> The argument is that the only way to do this robustly is to bundle an existing C compiler with the Rust compiler
> So C macros aren't the problem, but sort of the first worm that comes out of the can when you try to open it.
No. C macros need not be a problem at all, if you don't want them to be.[1]
And you don't need to bundle a C compiler - you just need to "bundle" a copy of the C pre-processor. The cpp is a *lot* smaller than a full compiler and can easily be provided as a separate utility (in the Good Old Days your cpp was a separate executable to the compiler proper), or even within the Rust compiler itself. Although, of course, one could reasonably assume that if you are trying to feed C headers into Rust, in order to link with C code, you already *have* a full C compiler and can just invoke that cpp[2]
In the not too distant past I had to set my Makefiles to run a standalone cpp over all the C sources before handing them over to a particular compiler because *its* cpp (which was built into the compiler exe) was crap and fell over as soon as an expanded macro went over 255 characters, so running it over C headers before processing them with Rust, or any Rust-related tool, is a perfectly reasonable thing to do.
[1] which isn't to say that there aren't problems to be encountered in C headers, just that macros are a total red-herring.
[2] look for the command line options to cl (or lc); if nothing else it is useful to know how to just run the macro phase if you ever need to debug some of the weirder errors that can creep in to your C/C++ code.
> though you may have to compile a list of the header files you want to feed to it
Which is why we have makefiles.
It doesn't matter that you need one, two or ten utilities to massage a header from one format to another, so long as those transforms are reliable, accurate and can be managed by your build system (which is under source control, like everything else).
Personally, I like having interface structure definitions in yet.another.text.format and using *that* to generate the C include files as well as the files for whatever the C is talking to - and at the same time, C/whatever functions to print the structures in human readable form, pretty diagrams for the documentation (by spitting out inputs for Mermaid or other diagram drawing tools) etc.
That way, *everybody* is equally pissed off at writing "those stupid weird definition files, why can't I just use (native language format)?". To which the reply is "You can, but *you* are then responsible for keeping everything else up to date and the machines *will* email every time one of them needs to be updated (aint Make calls to blat wonderful?)".
Absolutely.
Although they were unable to actually manage DIS admin tasks[1]: they didn't so much shut it down as never maintain it until it just - stopped.
[1] I ended up with three DIS hostnames and fixed IP, one pair active at a time, because as a major telecomms company (!) they could never figure out how to change the landline 'phone number when I moved! So had to close each account[2] and start up a new one.
[2] And to top it off, when *they* told me that they had to shut down the first account, *they* then came back to say that it could not be shut down because it was a "company account". No. No, it was always a personal account. "What if just cancel my personal credit card so it won't be paid for any more?" "We'll keep it alive and just send out the bailiffs". Did they have a contact name for this company? Yup, my name. So I can cancel? No, it must come on company letterhead! Aaaargh.
To determine the age, count the rings of spreadsheets.
Look for the Apple ][ on life support in Accounts Receivable running VisiCalc that feeds to multiple Lotus 123 boxes in Shipping and Warehousing which export CSV to one IBM XT (the one with the new HDD card) running Multiplan to format data for Access which exports to a shared folder as a data source to an IIS webpage that is scraped into Excel sheets for middle management who retype the numbers into emails for the CFO's PA to put into a PowerPoint.
The monthly finance meeting has a standard itinerary item for the Accounts Payable guy to read from his Dataday pocket ringbinder. The final answer to "what is the age of this system" is written on the reverse of the 1980s London Underground map at the back of this weathered leatherbound volume.
CTO's summary: The Requirements Spec phase of the ERP transfer is entering its third year and we remain optimistic.
The issue is that if you write out the entire type you start to think "hang on, this declaration has four nested containers, how big is it, shouldn't I be taking care here?".
If you just fling "auto" everywhere you don't think at all about whether you've just copied an int, a float - or a complete DOM of a gigabyte XML file.
"auto" is neat for making some templates work, but just flinging it around everywhere because you can't be fagged to find out what data structures you are playing with - worse "it just saved me typing" - is a recipe for wasted resources and potential costly disaster.
> who missed the optimization potential at the beginning
Everyone. And rightly so.
The order is: make it work; make it work correctly; make it work fast.
If you *think* you see an opportunity for optimisation in the first two steps, just make a note of it and carry on. As soon as it is working 'correctly enough" to be functional, run it through the profiler. Then, and only then, locate the hot spots - both time and memory consumption, often intertwined- and improve those. Re-profile to find the next hot spots.
Otherwise, without data from the profiling, you will inevitably waste time on premature optimisation: the "slow code" you think you spotted may only run once a month - or it may even be excised completely by an algorithm fix whilst "making it work correctly"!
> (and who suggested/justified/ordered the profiling?)
You should always have in your plan the expectation of profiling (although I am horrified how often I've worked with coders who are "expert" with their IDEs and do not even know if they *have* a profiler or are worried when the answer is "no". It was shocking whem Microsoft stopped providing a profiler and nobody seemed to care!). Only drop - or postpone - that once you can see the program working and somebody properly signs off as "it is demonstrated to be running well enough".
So the question should be: "Who *stopped* the profiling? What was their justification and was it valid at the time?"
Lots of times, it is really easy to see that profiling and optimisation are not necessary - because (numerically) lots of time you are involved in only a short program, a one-off tool, probably just flung together, run and forgotten about. Great. But even then, good practice is to write down "I did not do this stage, it wasn't necessary/useful, signed Burt".
> how much pressure were they under to "get it done, not get it done well"?
That is what causes the profiling to be dropped - and that fact signed off by the PM and manager of course (ha, ha).
BUT even after finding this saving of x million pounds and k servers no longer needed, saying "Why was this allowed to happen? Why didn't we find this out earlier? Ah ha, it was Fred's fault, he told them not to profile; sack him now" that is very possibly an over-reaction:
How much growth has there been in the use of the code since it was written? Is it now processing (k * 10) or more transactions compared to when it went into production? If do, and (being very, very crude) you can now shutdown k whole servers, at the beginning you could have only saved 1/10th of a server. Less easy to shut that down!
In other words, as time goes by, IF you experience growth, the balance of costs to fix versus savings made will alter.
As to "Can the same person pull off the same trick again? Was he the only one who could?" - highly likely those are pointless questions, because if your system has reached the point where one (lowly) person could ever be in the position to randomly say "I wonder what happens if I profile this?" then what you have found is a management and planning failure: you've grown but haven't bothered to think about what growth does to a system. You haven't bothered to go back and check how many profile runs were just not done etc. If you pay a bonus to the engineer - and you should - you should take it out of the manager' bonuses (yeah, I know, that'll never happen).
Reminder: the above is different from the situation that possibly more of us have been in, where everyone knows full well the program must get a speed-up, we even have all the customer complaints that it isn't keeping up. But nobody can figure out how to improve it, until Jim has his brilliant moment.
> If the US dollar has been put on a bro chain, and gold has been replaced with the pyramid scheme that is crypto gambling
And if the crypto used are the common ones, like Bitcoin, these are relying on there being enough random systems scattered across the Internet to maintain the chain, by mining. Which leaves them open to 51% attacks. Other mechanisms than Bitcoin's "Proof of Work" are tried in other crypto, but they all rely on "no one player can ever get enough - whatever - to take control". Where "whatever" can be how much drive storage you've collected or how much of the coin you hold.
So, the second that you (functionally) tie $US to bitcoin is the second that China switches all its GPUs and NPUs and CPUs, company laptops and after-school Maths Clubs to churning out Bitcoin hashes[1]. The US then gets to watch a brand-new "trustworthy" copy of the ledger floodfill across the Internet. What do you think that new ledger will say?
[1] or all those SSDs on Ali Express are "given a soak test" for whichever coin(s) use that stoopid consensus mechanism and so on.
PS
Ah ha, we'll just convert everything into one of those that listens to whoever has the biggest holding of that coin. And now the US government explicitly controls that coin, all the libertarians drop it like a hot potato. Also, it becomes impossible for the feds to ever divest themselves of the coin, because then they'll lose control of it. And something that you can't divest is no longer an asset, so poof, there goes the ability to borrow against the USG. Oopsie. Would you like us to pack the USA for you? Did you bring your own bags?
Close, but no banana[1]
It was Larry Niven, not his buddy Jerry (that page also has a link to the story itself).
[1] nowhere near radioactive enough!
Hacker?
Going by the handle realDonT?
In a rare case of actually thinking ahead, if his plan for Tsarship fails and he has to leave at the end of the four years, the cryptowallet will somehow vanish into his house at Magaritaville (or whatever it is called).
Leaving behind a lot of (by then) really pissed off cryptobros[1] who have to choose between letting him get sway with the spoils or running the coin value into the floor, taking their stash along with his.
[1] everyone will be really pissed off with him, this'll be after his plans for perma-Trump have ben revealed and failed, remember
Please go back and re-read the article.
The line you quote is clearly in the section, at the bottom, labelled "Alternatives" and, as the first paragraph says:
> For instance, it is possible to run an OS-level ad blocker
and then name-checks Privoxy as an example of a filtering proxy, which can be installed into your client PC's OS instead of expecting to be installed on a separate server, such as a Raspberry Pi or an OpenWRT router or (see above for other suggestions).
As you point out, you have determined that you can *also* run Privoxy under OpenWRT - in which case, you are using it in the same way as Pi Hole is being recommended - i.e. you are *NOT* running it as "an OS-level ad blocker" but as a LAN-wide blocker. Good. Neat. You have demonstrated that Privoxy can be run in BOTH modes. Splendid.
However, if you *had* installed Privoxy in "an OS-level ad blocker" mode - or run some other potential "OS level ad-blocker", especially one[11 which had decided not to allow connections from any non-local process, then you'd be in the situation that the article describes: needing a copy per computer.
[1] if there are any - I'd bet that some paid-for proxy works like this, if only to prevent its use LAN-wide without buying more copies
Heartily endorse running on a separate Pi propped on an old christmas peanut selection tin[1] next to the router.
As much as I have fun at home, playing around with VMs[2] and running three separate LANs in the one tiny household[3], it is so much more relaxing to have a simple little appliance sitting well out of reach of that madness: no need to worry that a little oopsie will bring down the wifely wrath.
[1] ok, tin is optional, but useful for holding backup SD card, just in case; and the nuts were tasty.
[2] keep meaning to try Docker, but NAS is FreeBSD and just never got around to it; VMs sem to do the job. One day, Real Soon Now...
[3] And, by sheer luck and random cheap purchases, I now have a small box with 5 NICs available - mwaaa ha ha!
>> What am I missing?
> Everything
> Description of a truly shit and out of control workflow - and workplace
Sorry for your situation, but no amount of bloat in the applications is going to fix that. Without a modicum of discipline, they will break anything.
Well, TeX does have all the extensions and helper packages that anyone could ever need. What other DP solution can give you anything like TikZducks?
(Icon: there is also TikZpingus if you that way inclined, but I mean, come on, ducks!)
> Let me know when they add spreadsheet functions
I don't pretend to be much of a desktop publishing person (what little I do do, I like to do with chains of command line tools anyway) - but I can't help but be curious what spreadsheet functions you think ought to be *inside* a DP program?
Affinity (claims[1]) to be able to pull data from Excel files as well as other sources, just like many other page manglers do[2].
On the (old-fashioned) basis that the best tools (try to) do one job well, so edit spreadsheets in a spreadsheet program then export results to another program that actually does a good job at layout formatting, wanting spreadsheet functions inside the DP seems like just trying to make yet another monstrous bloated lump which isn't much of a spreadsheet and is now a painful DP app.
What am I missing here?
[1] and therefore may be really bad at it, but that is a different sort of complaint
[2] if only for that old standby, a mail merge - that inevitably fails half way and leaves you passing around flyers for [event] [date] [location-but-not-that-awful-pub-the-kings-head]
The three rovers have managed to crawl from the wreckage. But alone, silent, without the Nokia base station, unable to talk to each other, let alone ask for directions from Earth - which remains unaware of their survival. They are left to drive (and jump) into the wilderness. The two wheeled rovers stay in sight of each other, for the company, until the NASA rover, in an insane fit of jealousy that the MIT machine has its colony of AstroAnts as its pets and friends, rams it and both tumble into a rill. Unable to climb out, the larger machines succumb. Leaving only the AstroAnts behind, to cannibalise the rovers' remains for spare parts and settle down into a small civilisation that worships the dream of, one Lunar Day, returning too the Holy Landing Site with its fabled Golden Foil Wrapped riches, the 4G El Doradio.
Of the rocket propelled drone's fate, no-one is certain, although the AstroAnts tell each other scary stories of a shape that appears for a moment above the lip of the rill as it travels restlessly, leaping, leaping, leaping.
We used to run those along tracks made in the sandpit, sometimes past castles, sometimes through craters (artisanal craters, made - when adults weren't watching - by artful application of "meteorites" thrown down as hard as we could). Not in the least bit competitive, of course. But - use a warmed knife to cut slices of a candle, pull them of the wick and thread the elastic through the hole; reduces the friction. And wooden reels are better (It were all better in my day!).
After that, pullovers for goalposts...