Posts by bombastic bob 10838 publicly visible posts • joined 1 May 2015
good point. You're supposed to be able to control access to location info for applications, last I checked, but how many people do NOT click "enable" for it when prompted?
Or... go through the list of pre-installs and DISABLE it
Is there a "master disable" settings feature yet? That should be in there, too - disable "whatever" for ALL applications no matter how loudly they whine [as an example] and, better still, feed them bogus data so they don't break. Well, I can wish, cant I?
my initial reaction was that the "micro-agressions" might have been the fault of the recipient by "interpreting them that way". This whole idea of "micro-agressions" and "triggering" nauseates me to no end. Unfortunately there isn't a "Vomit" icon...
Also, deep pocket lawsuits are (unfortunately) a possible motive for possible false allegations by disgruntled employees.
I thought we were calling them "Micros~1" these days...
What's nice about open source is that if you do not like what they did to it, you are welcome to fix it or contribute a patch to make "whatever that was before" an option so that you can have it back if you want it. A properly managed project would accept "an option to have it back" as a patch and integrate it so as to NOT anger a lot of existing users that agree that "change is NOT always for the better" and want their old "whatever" back. Or it will fork. Like Mate. Like Devuan.
(My mate desktops running on Devuan systems and FreeBSD look like an old Gnome 2 setup from a decade ago and it makes me very very happy that I _STILL_ have a 3D Skeuomorphic classic desktop)
github has been moderately stable except recently when they broke the appearance of tags [text now always black unless you have a bleeding edge browser version] and apparently aren't going to fix it so that it's compatible again...
you made me consider what fruit equivalents we could use for Micros~1 and for Google since "Apple" is already taken...
I guess Micros~1 is a banana and Google is a pineapple. Or maybe the other way around. Ouch.
I have yet to purchase a chromebook but the potential of 'just putting linux on it' makes it a worth-while gamble, as long as the screen is big enough. Or maybe, like an inexpensive 'droid slab (i have one 'o those), it becomes "fit for purpose" when used as intended. After reading stuff here, that last part is probably most correct.
/me needs coffee now
Being "Intar-web Street-Wise" is *THE* solution.
"A sucker born every minute" - and twice as likely on-line.
Here's what _I_ think: Question _EVERYTHING_, especially when EVERYONE *APPEARS* TO BE SAYING THE SAME THING...
The only protection, for you, from "Teh Intarwebs", is YOUR BRAIN.
(but of course, THIS assumes that INDiVIDUALS are personally responsible for their OWN lives, and lacks an elitist point of view that "the elites" should be "making it safe" for "the prols" because they're not smart enough to do it for themselves)
blocking script is the only way to be "safe". Unfortunately a lot of sites break when you do this. Although I can avoid them 99% of the time, I still have a "special login" that runs without noscript, for those times when I have to cave to their nonsense.
Hint to El Reg: Script is why ads should be showing up on my browser, but they don't. You could fix that, and ALSO show the world that you do NOT need script in ads. Win-Win
I wonder if Google'w bureaucratically minded approach was already being used for the browser's updates...
If so, I'll LAUGH EVEN HARDER!
Though maybe the _REAL_ problem is the way web browsers have diverted from displaying hypertext mixed with graphics and interactive links into a "mini-OS" of sorts, written in of all things, JavaScript.
maybe they'll bother to fix another memory bug I've observed (and others online have been reporting for YEARS), where [under certain conditions] if you leave a page open that frequently "phones home" and does a periodic query across the network (let's say updating status text, like a weather monitor), that in a particular use case the memory footprint will slowly increase until something crashes. It's been like this, since, forever I think.
I would be more sympathetic to their union if not for the fact that this union was, in part, started over objections to the 'Maven Project'. And though I agree with the their dislike of a "real names" policy, it's usually the point of a union NOT to dictate corporate policies and contracts, but to protect rights of employees and in doing so provide needed services to the company they contract with.
So I have to agree with the idea - if you do not like working for Google, there are other employers. I know _I_ would not like working for Google. So I don't.
I'm not against unions, but I don't see an I.T. union being all that effective. if it were more of a guild, where it acts more like a standards setting organization and even provides employment "head hunter" services, it might make sense.
please let me know (with proof) what 'lies' you are referring to. Thank you.
Jeanine Pirro (one of the defendants in the lawsuit) used to be a judge. On her show she's known as "Judge Jeanine".
I would think that Jeanine Pirro would have a pretty good grasp of evidence, evidentiary rules, and so on with respect to what might be considered libel, slander, or "damaging". Many other hosts on Fox News are actual attorneys.
So far I haven't seen anything like "lies" that would result in any kind of "damage", and I watch Jeanine's show regularly.
And though I don't always watch the others named in the lawsuit, I haven't seen anything "damaging" from them, either.
Please keep in mind, THIS.
I expect to see more of the same in the near future. the thing about a court case is that actual EVIDENCE gets to be presented, and DISCOVERY gets to be demanded from the opposing party.
You don't need to verify the identity of the person who did the change when you can look at exactly what was changed.
Correct. And it's theoretically possible to grab a source tree based upon a specific commit, or a specific version, if you need to [for patches, at least].
What you do *NOT* need is "da bleeding edge newest feature-creep-laden" version, EVERY! SINGLE! TIME! you update.
What I see as the problem: Someone "not you" is deciding what version of code is being used by your application or operating system.
What I see as the fix: enable software authors and package maintainers to depend on installing older (or newer) versions of critical libraries if they want to, with forked security patches, as needed.
What needs to happen to make this work: either static link the binaries and manage them individually, or else use something similar to a "container" or "run environment" to be installed with specific package versions assigned to critical (or otherwise incompatible) packages. Ubuntu may already have "a mechanism" for this....
Just because a shared lib exists on the OS does not necessarily mean you MUST depend on it. Your critical package dependency tree could easily depend on versions that have been PROPERLY VETTED, and maintain security patches on.
To some extent, an LTS release will do this. By fixing code versions in stone, and ONLY patching vulnerabilities, you generally are NOT introducing NEW ones. Prior to a Linux release that's LTS, responsible package maintainers would vet all of these things (and prevent breakage).
Long ago I realized that you can NOT rely on shared libraries being updated to NOT break YOUR application, especially if you ship binaries. To some extent Linux handles this by versioning the names of the shared libs, but this does NOT correctly patch security vulnerabilities if you update ONLY THE NEWER VERSION of that shared lib. This patchwork "must be a shared lib" approach is flawed in this way. As I see it, for any critical application, you either include your own libs in the build process and link them statically (or dynamically with unique-to-your-application names), or you use specific LTS versions of the libraries as dependencies for your shipped binaries, thus ensuring that security patches (and not "FEATURE CREEP") are the only things done to them.
Things broke HORRIBLY WRONG when everyone "suddenly decided" it was necessary to maintain bleeding edge "feature creep laden" versions of EVERYTHING, and to CONSTANTLY HAVE A MOVING TARGET, in lieu of "stable, well tested, rarely changes except to fix serious problems" .
Change and re-inventing the world, because, "new, shiny" - SO HIGHLY OVERRATED!!!
Has anyone done ANY meaningful benchmarks?
I did some study on entanglement a while back and it seems that what you need is hardware that can produce pairs of electrons or photons, as a single Qbit, a particle pair that is entangled (the 'opposite ends of the superconductor' method might be the best one yet) , and then somehow you leverage this entanglement to do computing tasks for as long as the Qbit can remain stable (which, apparently, is NOT very long).
But if you use simulation software to create a simulated QBit, how is this ANY better than just doing normal maths??
Nothing I have read so far EVER goes into specifics on how to make this work. Maybe it's time to grab that QDK and see how it can actually be used. I'm sure SOMEONE must have SOME kind of sample code out there, even if it's only doing some mundane chaos calculation like "sun spots".
A practical example is needed...
nice use of the joke icon to make a point. I wholeheartedly agree!
/me points out that since that "few million lines of lines of code" is relatively STABLE and WELL TESTED by time, there's really no need to play the "Arthur C. Clarke's 'Superiority'" gambit only to end up the loser and ALSO not knowing how it happened...
The one thing that I found that C++ helped a lot with (in windows coding) was the ability to manage GDI handles automatically, freeing them when no longer needed. This also assumes that you're not abusing exception handling and that object unwinding functions properly if you do.
Otherwise, my C++ code nearly always looks a LOT like C code. Personally, I think it becomes more maintainable that way. Properly designed templates and operator overloads can help, too.
(but if your C++ code throws exceptions and requires try/catch everywhere, you're doing it wrong)
One thing that I believe Micros~1 got mostly right is the COM object for OLE 2.0 . It kinda demands C++ and, by design, helps to prevent memory leakage and similar things. You could make _THAT_ a qualified "citation" for mitigating SOME of the things that shared objects and object lifetime issues might otherwise cause.
according to the TIOBE index, C is WAY out ahead in popularity at ~17.4%, Java is just shy of 12%, followed by Python at ~11.2% and C++ at ~7.6%.
Rust is pathetically in 26th place at 0.61%. Even assembly language is doing much better than Rust, in 11th place at 1.64%.
(note these are still January numbers and so it might change around a bit when Feb numbers come out)
Anyone who bitches about writing code in C should provide a link to the operating system alternative, since I can't find it in my version of Google.
heh. so true.
there've been plenty of "code smell" and "code pattern" web pages (or even dead tree manuals) written regarding the *kinds* of things that get you into trouble with C coding, like best practices and things to avoid. I would think that reviewing and understanding the more sane and concise ones might be "step 1" in contributing to any public project _like_ gpg, OpenSSL, etc..
(And if that's not good enough, a clue-by-four and/or cat-5-o-nine-tails)
poorly written/reviewed C code, you mean.
last I checked, compiler warnings in llvm should spot a lot of buffer-size-related issues. It's not perfect but apparently will spot many things. As a test, I called 'strncpy' with a buffer that is too small for the size I specified in the 3rd argument, and got this warning: "warning: 'strncpy' size argument is too large; destination buffer has size 16, but size argument is 32 [-Wfortify-source]". But using 'strcpy' with a string that was too long in the 2nd argument gave NO warning.
Suffice it to say that the big problem here is "NOT using" code that checks buffer size, and hopefully if you DO use code that checks buffer size, that code warnings are paid attention to if you accidentally get it wrong.
And, of course, best practices and peer review to go with it.
the West does not have a monopoly on smart scientists and researchers
this may be true, but because of the CCP (and things like "social credit score"), it is my impression+opinion that engineers in China tend to defend higher ups or "status quo", even when blatantly wrong, in lieu of taking an initiative and getting things done. It is my opinion that they are fearing for their jobs. Were it not for an NDA I could describe a situation in more detail where an OEM product started to fail after they made an unannounced design change at the factory in China. I assisted in troubleshooting the root cause, and proposed a solution that was a compromise between the old and new designs (it worked perfectly when tested, and many units were retrofitted with the fix). The solution was basically rejected (keep in mind it took the form of a customer request), with no real reason provided, almost like a denial that the problem even existed. Much later the engineers in China made a "fix" that was, in short, like "using a bigger hammer".
A decade ago, I held in my own hands a counterfeit Cisco switch that included a hardware backdoor that was traced back to China.
A bit worse than outright copyright theft [which I have seen evidence of back in around 2008-ish].
I was working for a oompan that made antennas, designed in the USA, but made in China and sold to other companies in China. During a meeting they showed (on a projector display) an antenna that had been produced in China, not by a licensed manufacturer. The antenna had similar performance but of course was WAY less in cost. The thing is, the designer of the antenna worked the company logo into the design such that excluding it would de-tune the antenna and ruin its performance. An X-ray of the antenna showed that the company logo was there, underneath the plastic, but "fuzzy" like it had been copied from an X ray of the original.
But I have not seen cases where software or firmware had been deliberately "back door'ed". I had actually written a lot of that firmware myself, based directly on the SDKs for the chip makers (Broadcom, Atheros, TI, etc.). So I cannot attest to a back door, but I _can_ attest to the copyright fraud. Still, it does NOT surprise me in the least.
And, being "in the industry", I can definitely understand HOW a hardware back door into one of these embedded systems COULD be done. The fact that it was (apparently) tried at least once should make the rest of us VERY suspicious until complete trust has been ensured.
I was just thinking of that, the Tulip market thing a couple of centuris (or so) ago.
https://en.wikipedia.org/wiki/Tulip_mania.
Also demonstrated in fiction, in the 2nd season of 'Spice and Wolf' (pyrite market manipulation)
Still I have some Schadenfreude for the hedge-funders, one in particular [and no news whether or not this person, "the man who broke the bank of England", lost any significant money in this, but he probably DID].
Normal stock investors are long term, and a rising tide lifts all boats. The hedge-funders are basically selling SNAKE OIL and making money at the expense of others. Like I said: Schadenfreude.
Almost every business on the planet
For JVM and Python on the BACK end? You forgot to consider PHP, particularly within a Linux hosting environment.
JVM not so much either... not unless you write Java desktop applications or Android applications.
Python on the backend, seen that - with DJango. i hope I never see that AGAIN.
At least with Java, future devs will be able to do client applications and not just web pages. It's like a stepping stone for a native (read: proper) language like C or C++. Heh.
Python, on the other hand, seems to be way too encumbered with its "scriptiness". For a beginner I'm sure it seems cool, just like BASIC did back in the day. However, for writing maintainable and reliable code that's not overly dependent on 3rd party library HELL, or [worst yet] NOT having some incompatible change made to Python itself, And 'pip' is just a stopgap that hides the weakness, especially when downloading 'the latest' breaks something. And so I do not believe it is quite ready for "prime time".
Still I think Python is great for LEARNING and quicky scripts and prototypes and wrappers for things like GTK and WebKit. But I wouldn't write a commercial application with it
It's also good for demonstrating an algorithm or a process to people who are novice programmers. chances are that if your example is in Python, they will be able to run it and learn from it.
Not surprised it's top of the rankings for a school that is teaching programming.
you can find leaks in high pressure air systems by squirting soapy water onto the suspected location, and it'll form bubbles and foam where the leak is.
A similar substance might help find them in a vacuum. It would have to maintain a liquid state while in a vacuum though.
Alternately, how about a gas that produces a recognizable signature, glows under UV light or turns into ice crystals as it expands into the vacuum, or something equally visible that you could shine lights on and see "something" out in space... ?
Certain CFCs mixed with oil or alcohol might do this last part, and then you'll see reflective things coming out through the hole [which would then sublimate, but hopefully if the right combination would show up long enough to see the leak]. Hopefully would show up in a visual scan of the outside.
Also a possibility, there's a kind of tire filler (like 'fix a flat') you can use for self-repairing bicycle tires, which if it is contained within a layer between an inner and outer wall of a compartment, could self-seal against most leaks. This would be pretty cool if a module were inflatable, as the outer skin could be layered and contain such a material. I guess it'd be "fix a flat" for the ISS.
does anyone happen to know WHICH version of DevStudio caused this possibility?
I've been using 2010 for a long time, mostly because I *STILL* target Windows 7 [and earlier] and I *REFUSE* to use an IDE with a 2D FLATSO interface. I do _NOT_ write "UWP" crap, either.
But now it may seem that I have even MORE reasons to _NOT_ use a newer DevStudio, if project files that it opens can SPREAD MALWARE like opening a spreadsheet, or a Word document, or using Virus Outbreak (MS Outlook) for e-mail... [assuming more zero-days exist for it, as past performance would indicate]
Micros~1 you need to get your act together on security.
(captain obvious now goes back to working)
I've been having to repair a lot of things recently, for whatever reasons [probably because the stuff is just old], like game consoles, monitor, even the KVM. More than half of it was NOT purchased on Amazon. But the rest was. Still I think I've spent less on Amazon over the last year than in previous years.
I've also been trying to use 'other than Amazon' when i can. At the very least, my choice causes me to compare prices and delivery time/cost against whatever Amazon is offering. But sometimes it's about business, and prices, and service and "nobody else seems to have it". Still looking for those alternatives, though.
I just hope that, for any site that (unfortunately) uses captcha for anything [sometimes even government sites do this, like for renewing your car registration], this new "de-googled" version of chromium doesn't become as *BROKEN* as I perceive Firefox to have become. It has been my experience that the more heinous captchas [like the slow fade-in fade-out ones] nearly always FAIL with Firefox. Whether it is because I'm using a 1.5 year old version of Firefox, or whether the various privacy features in Firefox (even with scripting and cookies enabled) is causing it, I do not know. It is merely an anecdotal observation, along with my bombastic opinion, but I think I'm right about it.
And the API issue with existing chromium kind of supports what I'm thinking here, that non-google browsers get INFERIOR SUPPORT from google. At least, that's MY take on it...
Got the bulls (us) by the *WHAT* now???
[good thing I don't use google things, at least not directly]
I've never had a problem setting up nor using bind to serve up any kind of serious DNS stuff, like a local LAN or a private domain name.
The only thing I've ever used dnsmasq for was a simple DNS+DHCP solution for a user to configure networking on a standalone embedded device via a phone or PC with a wifi connection. And since dnsmasq allows you to specify a single hard-coded name to connect to, you could set up the embedded device so that you press "the button" on the device for "config mode", use a phone to access it via wifi, then go to the web page "http://admin" (or whatever) and get a web page to configure it with, and have dnsmasq also provide the DHCP address for the connected device, etc.. Simple stuff like that seems to make sense with dnsmasq, and you have to press the right buttons on the device to make it go into config mode like that [after which the device would have its wifi client set up and would go off and connect through the LAN and use the LAN's DNS and DHCP, etc. and not its own]. So dnsmasq is never facing a public internet with this particular use.
Trying to use something like dnsmasq to do anything MORE than "what I described" might be the actual problem...
(for my own network I've been using bind and the isc DHCP server for both IPv4 and IPv6, no observed problems, and the bind server also handles DNS for a domain I own, and I've been doing this for almost 2 decades, though a bit less for the IPv6 part)
exactly - a 'Total Inability To Sustain Usual Parameters' event resulting in a ginormous "ooh, aahh" ball of "system integrity loss" would have cost a LOT more and set them back a LOT further. 400 additional seconds of fuel would make ONE HUMONGOUS FIREBALL, after all.
A look at Apollo 2 through 6 would confirm this approach (wikipedia articles on them are interesting and appear to be accurate). After Apollo 1, they needed to be more careful to identify potential problem before they become fireballs. Similarly with the shuttle losses. Space is (currently) a dangerous business, just like flying was 100 years ago.
pile driver is interesting. Such a device would ALSO be good for MINING operations...
* use a liquid explosive that requires detonation (but is otherwise stable), similar to those diesel pile drivers [but of course little to no air] with hydrazine or something like it
* the piston could be made of a lightweight material, then bucket-filled by a scoop and arm until it's "heavy enough" - once in place, that is.
* carefully designed pulley and cable to lift the piston (and drop it) so that the cable doesn't easily get all twisted when the operations instructions are sent with hours' delay.
* autonomous droid for the most part. I think we have the tech for this kind of thing already...
Field test THAT one, yeah!
oh and if hydrazine (or a similar chemical) can be made to work like diesel fuel on Mars or in space, so much the better! Imagine, piston engine space rovers. Who'd a thunk it? [a swashplate design might work best]. Add peroxide to the hydrazine for an even better burn!
A couple of years ago I experimented with Wine and discovered there are some serious shortcomings. One of the biggest: having BOTH 32-bit AND 64-bit running at the same time. Basically, did NOT work.
This completely screwed the ability to load things like DevStudio onto a Wine machine, or (for that matter) ANYthing that's "mostly 64-bit" but has some 32-bit executables here and there for some reason.
I was also disappointed in the *MESS* left behind when I went to uninstall the various wine packages in that particular VM. It wasn't pretty...
This _was_ more than a couple of years ago, so maybe it's fixed, now? I was actually considering the possibility of contributing to the project at that time. I wanted developer tools up and running for that reason. It was both for this _AND_ for CentOS, actually, but both seem to suffer from the same *kinds* of "Catch 22" level problems, inherent in the very nature of the projects.
Icon because I like the idea, but am disappointed in how it has dragged along...
I don't think it's 32-bit ARM that's at 'RISC' here (bad PUN-ishment) but 32-bit i386 specifically.
Raspbian/RPi OS is still 32-bit last I checked, though FreeBSD had 64-bit ARM for RPi 3 a couple of years ago.
embedded systems are still widely using 32-bit Linux for ARM (or in some cases MIPS I guess). It's smaller and runs slightly faster due to address width.
Not sure how many embedded systems [other than legacy] are using 32-bit i386 though. And maybe that's why they are considering dropping it. [although I've got some old Pentium III computers and motherboards that could be used for testing if they want 'em]
here is the ACLU's position:
(I sometimes agree with the ACLU, especially when it comes to individual rights and privacy)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
