Re: Bogus
totally
10944 publicly visible posts • joined 1 May 2015
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)
some news reports say that violent protesters used Tw[a,i]tter and Fa[e]ceB*** last year to coordinate THEIR illegal actvities (riots, looting, autonomous zones). But I guess they have their OWN servers and aren't using AWS.
you can't really STOP criminals from abusing a platform. Trying to police all of it would be a monumental task. AWS was too quick to pull the plug.
For those engaging in criminal activity, USENET and IRC would have been easier, In My Bombastic Opinion, unless they were TRYING to get Parler in some kind of trouble along the way...
As for Parler using AWS, "all eggs" "one basket" and a few other things come to mind. Parler needs to NOT rely on JUST "the cloud", and particularly NOT a single cloud provider. And AWS seems to have proved themselves to be at least a _little_ hostile to their potential customers. It gives me pause for thought as to whether AWS or _any_ "megacloud" provider is worth the effort.
A 'private cloud', distributed geographically on servers and pipes that YOU own, would make a bit more sense. I've been pricing ISPs lately and have looked at quite a number of them, for a customer and for myself as well. Things *LIKE* AWS could STILL be a fallback when a sudden need exists for peak bandwidth. So the only cost of "you are off our platform" would be some temporary slowdowns.
Perhaps we should ALL consider this as a "what if this kind of 'cancelation' happens to ME" warning... that is, BEFORE putting all of our eggs into AWS's (or anyone else's) basket, and relying on NOT having some arbitrary, capricious, or even MALICIOUS decision by a provider (or group of providers) cripple our business.
I think that flash COULD have lived, but to do so, they would have needed to go open source and allow the community to assist with the security fixes.
For a while there was something called 'gnash', a 'gnu flash' for those who've never heard of it. it worked pretty well for a while, but then flash kept adding things and adding things and changing things and making it incompatible with older players and nobody updated gnash... so it *died*.
(Hopefully I've already described the situation well enough that the implications are obvious now and I don't have to become "Captain Obvious" and boringly explain it 'cause I'd really rather not)
From the article: Agree with other damn developers where you're putting your damn accessibility settings
First thing that entered my mind was to use the desktop settings so that it's doing "accessibility" out of the box already. FreeDesktop does a walkthrough here:
https://www.freedesktop.org/wiki/Accessibility/Walkthrough/
As for windows I _ think _ it is built-in (more or less).
There's also supposed to be an Accessibility API for 'droid. I haven't actually used it (yet) but was under the impression that such settings _usually_ show up automatically...
I thought this had been settled by the OSs but maybe not.
FYI - most of the standard menu arrangements and hotkey assignments were defined by Apple and IBM.
With the Windows 3.0 SDK came a dead-tree manual on IBM's user interface spec. It was designed for OS/2 but Windows also complied with it, more or less, at that time.
I might suggest a common hotkey for application accessibility settings... maybe ALT+A or similar... (apparently i-things have a configurable button for this).
This wikipedia article has a list of common keystrokes used by winders and gnome:
https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts#Accessibility
For touch screens, what would work best? Needs to be easy for people with finger muscle issues or voice-only interfaces.
a general comment - default user interface colors that are NOT light blue on bright white, especially if ANY visual accessibility feature has been enabled [just assume it please]. That specific color combination [I'm talking to YOU, Apple, Google] is EXCEPTIONALLY HARD on eyes over the age of 50.
(respecting desktop themes would ALSO help a LOT, if not being done already)
Last I checked, people are still making 486-based CPUs for things like the PC101 platform and other stuff that's mostly for embedded systems.
changing a hardware design might be difficult. But new designs should _DEFINITELY_ use something else [like ARM].
The question is whether or not these legacy systems have any new development or need for security patches...
But it's worth pointing out that, on platforms that can use both 32-bit and 64-bit [most x86 and ARM64], the 32-bit code is probably going to be a little bit faster, and a little bit smaller, due to 64-bits vs 32-bits for memory addresses. Abandoning 32-bit support in its entirety would be a MISTAKE.
But abandoning support for older processors... I guess they could just let the people who actually USE them submit patches themselves. THEN the cost of maintaining the legacy hardware vs maintaining support in the kernel might change something down the road [and devs can spend more time working on things that are more relevant to most of the Linux implementations].
sorta reminds me of the 80:20 or 90:10 [or whatever] rule, about 80% of the code taking 20% of the effort, and the other 20% taking 80% of the effort, usually supporting features that are used a fraction of the time, but taking up WAY too many resources to do it. Just a concept, but seems to be accurate In My Bombastic Opinion.
What this needs is an acronym.
From the article: the report calls for better software defect detection and remediation of identified vulnerabilities
B.S.D.D.n.R.O.I.V (ok maybe not)
But I usually solve these *kinds* of problems through Super High Intensity Testing.
And that's an acronym that's easy to remember!
I think the point of mentioning FetchAllTheStuffJustInCase() was an example of DOING IT WRONG, and yet this kind of *BAD* *PROGRAMMING* appears to be WAY more common than anyone might want to admit, from the horrendous amount of unnecessary java script in web pages, and the use of GINORMOUS (and generally unnecessary) 3rd party javascript library downloads from various content servers scattered around the web, to the length of time it takes to populate a "File Open" dialog box with a list of more than a handful of files... [and gnome-based and even mate-based desktops, I'm talking about *YOU*, too].
NATIVE CODE is nearly ALWAYS better. Do only what's needed, and do it on the server. And it should be EFFICIENT code, and not "grab everything _AND_ the kitchen sink, 'just in case'". You don't need to thumbnail every file before you can select one, as an example, especially when a directory contains HUNDREDS or even THOUSANDS of files... example, do a gnome or mate 'file open' on files in /usr/bin - see what I mean?
At some point the server operators will STOP stealing CPU from the clients and realize how inefficient their processes have been, when they NECESSARILY move it to the server side and discover the resources that doing things "that way" actually consumes!!!
You know what "real" engineers and architects do for the majority of the time? Yeah, its documentation
Sadly, no. [although I'm doing docs at the moment, seriously]
I run into 'lack of proper documentation' a LOT. I think most others do as well. If "Stack Overflow" is the best source for information on a programming language or platform, then the official documentation is either poor quality or missing.
someone remind me of how the 1929 stock crash happened, again??
At the center it had something to do with BANK SPECULATION and the loaning of money to people to PURCHASE STOCK, as I recall...
Yeah no resemblance *HERE*. Not like crypto-currency COULD be manipulated easily or anything. I heard this happened to the GBP a few years ago. What was the name of that guy wot dun it... "broke the bank of England"... right on the tip of my tongue...
"That's the point of capitalism evil capitalists
fixed it for you.
the point of capitalism is for people to earn something of value based on the value and quality of their work, and then use that 'something of value' (like money) to purchase goods and services, etc. the way that human societies have worked since prehistoric times. It has NOTHING to do with exploitation. Evil, on the other hand, has EVERYTHING to do with exploitation. And that's the point.
but whether the people behind Qt's heading-towards-closed-source maneuver are evil capitalists... that will most likely become obvious at some point.
One of the best things I like about wxWidgets is that it's possible to port an MFC application to one that uses wxWidgets if you understand the differences well enough. Other than names of functions, which could be a set of 'sed' lines in a shell script, you have to alter how windows messages are handled as 'events'. it's similar but not the same, and requires actual though to re-write it, but I've done it a couple of times and I like the results.
As a result, if software had been written in C++ using MFC for Windows, chances are a Linux version or a portable version that uses wxWidgets for both windows _AND_ "everything else" could be practical.
if you make shared libs with C++, at least make sure no symbols are exported that aren't declared 'extern "C"' especially if you want 100% compatibility between, let's say, both CLANG and GCC applications using it...
what you do INSIDE the library should be abstracted and encapsulated, anyway. Anything ELSE would be bad programming habits.
then other languages (Python, Perl, etc.) could have bindings to your library without too many hoops to jump through.
I was _EXTREMELY_ disappointed when KDE appeared to go "all 2D FLATSO" like Win-10-nic and the chrome browser and "Austrails". Is KDE's 2D FLATTY-ness a direct result of changes to Qt? Because if that's the case, what's the point of anything 3D (like best-case use of 3D acceleration) in future Qt versions, if it's *IRONICALLY* 2D... [and OpenGL is still "a thing"]
it's not impossible to have dual licensing, a GPL license for any open source project that distributes it, and a private non-GPL license for people who want to ship binary-only versions. since the creators own the code they can do what they want with it, pretty much, even if the two licenses conflict.
Seriously I like to offer both a BSD-like or MIT-like license along with GPL for stuff i put "out there" as open source, and THEN give whoever distributes it the choice of which open source license to use. Wanting to control how people use something (you can't play with MY toys unless you do it MY way) isn't very "free", In My Bombastic Opinion.
It's sorta like: if you give a gift and then dictate (too many) terms on its use, it's not a gift, it's more like a lease.
Batteries are designed to be replaced
Ideally not so often that you might as well use throw-aways
(from the article)
batteries comprised of more abundant materials
This _I_ like. I've heard good things about Aluminum-ion types of designs [whether its exactly that, or some derivative of it]. Lithium being a 'rare earth' material would eventually make it more expensive. However, other materials that are much more abundant would make "better" batteries that are physically larger and heavier. For many applications the latter battery might actually be a better idea. I'm thinking hybrid cars and inexpensive laptop computers, specifically... things that an extra pound or two isn't gonna hurt, especially when minimal cost is one of your goals.
As for overall capacity, the improvements made to lead-acid batteries over the years to extend THEIR life hit a kind of plateau but still might reflect the *kinds* of things that could be done to LiPo, such as a method to increase the surface area of the lithium side, better electrolytes to improve power density and recharge cycles, yotta yotta.
But yeah, those damned laws of physics and chemistry keep getting in the way of our battery pipe dreams.
dendrites, I assume similar to 'whiskers' in electronics, except inside batteries...
one method that seems to work about half the time in old NiCd batteries is to short them out, rapidly charge at several times the C rating before it starts to overheat, then rinse and repeat until it holds a charge. I've done this both successfully AND unsuccessfully. YMMV. Don't let it catch fire.
not sure how you could address that with a charge controller. Single cell systems maybe, but multi-cell systems would get cell reversals and other serious problems. Maybe ICV detectors to indicate where the bad cell is and either auto-jumper it or shut down the battery so you can manually jumper it out. That might work, actually. But it would only extend the life of the battery array, not the cell itself... and single-cell things (like phones, slabs) probably wouldn't benefit.
during deep discharge, cell reversal is a major problem, so maybe ICV montoring could extend discharge levels by allowing you to go beyond the usual volt limits as long as there's no cell reversal...
I recall that back in the DOS days the chkdsk program was SO bad [creating a bunch of cross-linked files more often than not] that the ONLY way to properly fix the file system was to use Norton Utilities.
But for this NEW b0rkage, if I read the article right, you could do a chkdsk /f in "offline mode" (or is that recovery mode?) and manage to recover the disk. Or is this NOT the case?
I know how easy it is to recover a b0rked Linux system. I normally use set of tarballs, then re-install the OS and un-tar my backups onto the system. You could even partition it yourself and use tarballs to restore the ENTIRE OS. This is the opposite with windows. The registry nearly makes that IMPOSSIBLE without ghosting the entire drive. And specialized Windows backup software does NOT impress me.
I have always found SSH keys the most convenient to use with Git operations, whether on GitHub or anywhere else
This may be true until you are working with multiple embedded devices, and workstations, and have to either AUTHENTICATE EVERY SSH KEY for EVERY DEVICE [and then make sure you erase them when that device gets turned into a test platform (where you still need github access to update it) and THEN suddenly ends up at a customer site for evaluation before you can say "OH CRAP NO!". So even if you erased the source repos in time, you still would need to deal with those ssh keys in ~/.ssh/ ...
and... where can I safely store this alphabet-soup token such that it can be *EASILY* copy/pasta'd onto ANY device... ? yeah, thought so. And don't say 'USB stick' - some of the embedded devices will have all of the ports occupied already, for devices they control, at least for the stuff _I_ am working with.
And access to YOUR login from "any machine" (remote workstations and embedded devices included) is a necessary feature sometimes. This way, anyone (or any device or workstation) needing a 'git clone' could get a quicky copy of the online repo without jumping through unnecessary hoops. Cheapo paid-for version of github limits the number of collaborators, after all...
So many potential problems with devs like me, and yet independent devs or devs with individual logins ONLY dedicated to a particular company's stuff [and it's never "accidentally deployed"] won't have problems with this sort of thing.
the only thing WORSE than this would be 2FA requiring a phone or e-mail to your home e-mail address [when you're on site and not having access to it and you don't want *THEM* having your cell phone number] in addition to user/pass and/or tokens.
I've been using KeepassXC (the non-mono one) lately. works pretty well, and is still being maintained last I checked. I have a nice long true 'pass phrase' that I make mistakes typing in a lot, but fortunately there's an eyeball button so I can see what I just typed... and then correct it.
So how does it work if you have multiple devices using a connection.
I can think of when this could really cause a problem, for me at least.
a) Company has a paid-for github site to store source on, allowing 'work from anywhere'
b) each embedded device I'm using for development has one or more copies of a github repo [sometimes different branches pre-checked out for comparison, let's say] and I'm constantly doing git pull/push from these various repos in various places to sync up with the online repo
c) I can type in my password, which is complex and long, fairly easily. and I don't store it anyplace. My fingers do the motions accurately at least 90% of the time. It's over 10 characters long, has numbers and symbols in it, etc..
So, what must I do *NOW* - copy/pasta a token from "someplace" every time I use git? STORE THE TOKEN(S) ON EACH DEVICE??? (*NO*!!!) This could end up creating a very unpleasant experience, effectively *PUNISHING* those of us who use proper passwords, because a *FEW* do *NOT*. it also may force updating the git software, WHICH! YOU! MIGHT! NOT! WANT! TO! DO! FOR! EMBEDDED! SYSTEM! DEVELOPMENT!!! You know, STABLE KERNEL and NOT having to deploy KERNEL/USERLAND UPDATES for air-gapped equipment because "some package" was updated on a dev system and NOW the compiled executables won't run... or a behavior changed... or something like that. yeah even Linux has package-dependency-hell to deal with, and when package 'a' drags in 'b' 'c' 'd' etc. and/or forces updates, it COULD (potentially) end up being a mess. And I really did NOT want to include 'selected .deb files' on the USB drives to update firmware, and have to test ALL of the NEW OTHERWISE-UNNECESSARY 3RD PARTY edge cases to avoid midnight phone calls. yeah I like to TEST before deploying,.
when their actions become anti-competitive, when their business groups (search vs Android vs Chrome) collude to maintain a (alleged) monopolistic status, and when they are (allegedly) CAUGHT red-handed filtering search results for news articles from competing sources (read: Breitbart) or on topics that Google's corporate policies essentially "disagree with" [thus no longer operating in the public interest, in an anti-competitive way, even with political 'contributions in kind' that include restricting free speech and the free flow of information], then they have (allegedly) violated existing U.S. laws and SHOULD be sued and broken up into separate business entities that can NO LONGER cooperate at levels not available to non-Google businesses. This opens up competition, such as NON-Google browsers and NON-Google search engines pre-loaded onto Android phones (that would be ONE such example).
This was done with Microsoft in the early 90's, in case people forgot. Back then, MS Office was leveraging undocumented features so that Word wouldn't crash, but WordPerfect might, due to bugs in Windows 3.x that would cause a 'UAE' screen. I started using undocumented functions too, having discovered the problem WAS caused by bugs in Windows, and that 'GlobalHandleNoRIP()' could validate memory handles and prevent the UAE screens from happening. And eventually Microsoft had to actually DOCUMENT THIS (and similar functions) because their Office business group was, in fact, using them for that very purpose, too. it gave them an unfair advantage to have inside information and actual documentation for these functions, which nobody else had (and could only hope that the names or DLL ordinals didn't change in the next version of Windows). And, of course, let's not forget the integration of the Windows '9x desktop with Internet Explorer... which caused a WHOLE NEW set of anti-trust actions.
At least, that much I remember pretty clearly.
I could go on about Google's purchase of DejaNews, which seems to have been taken over and then dismantled. I have to wonder if any OTHER technologies have been so (poorly) treated by Google, reminiscent of "Embrace, Extend, Extinguish". That's pretty much anti-competitive, too, essentially buying up your potential competition and then dismantling them.
If you do not have the correct certifications you are assumed to be an idiot and completely unqualified
Only by idiots (and H.R.)
Even degrees are completely worthless in many respects. I started out without a degree, was taking (just) programming classes but decided early on I didn't need it. EXPERIENCE is _REALLY_ what matters, and hiring managers who do not include "or equivalent experience" in the job requirement are asking for a bunch of inexperienced PFYs to flood them with their "degree-based" resumes and little to no actual experience [which means you'll have to teach them "the difference" between shinola and 'that brown stuff', or their arses and a hole in the ground - that sort of thing].
(I was actually hoping this cert thing was for DEVICE DRIVER SIGNING or something _TRULY_ useful, but once again, my bubbles are bursting with disappointment)
unless the github cookies are used cross-site they'll just be showing how you view other people's repos on github. Somehow I don't think it's all that bad, if no advertising nor "what you see" adjustments are made from that info.
(that doesn't mean there's no 'web bug' on other pages that sneaks a peek at the github cookies to see who you are - that is STILL a possibility, right? Then again so is your IP address in some consolidated tracking database someplace)
Thinking of cookies (in general) there used to be this one plugin [that no longer works nd I can't find an equivalent last I checked] that could put ALL non-white-listed cookies into memory and NOT persistently on disk. You could click a button in the toolbar that would "flush" the memory cookies. Also they'd disappear whenever you closed the browser. So, not only could you white-list only CERTAIN cookies remaining after you close all sessions to that site, you could 'grey list' OTHER cookies so they'd work long enough to get past the analytics crap that login processes seem to want all too often. Then you can FLUSH those things when you're done.
That would make an EXCELLENT built-in feature, wouldn't it? But Firefox's UI changes broke th3e old one (as with many other UI-related plugins I liked having).
yeah, using l33t5p34k to encode your favorite word makes it SO much more secure... </snark>
(although I admit doing that when certain password verifiers won't let me do something more secure and easier to remember like an equivalent of 'correcthorsebatterystaple' and then confuse you when you have to use 3 of 4 different things, and if you use all 4, it rejects it...)
Making them as safe as possible while still economic to operate is the top priority.
That's one of those contradictions that needs to be resolved in any aircraft design. If it were easy, anyone could do it. There are, of course, many other "design contradictions", like structural strength vs weight, fuel capacity vs range, seating comfort vs packing enough people in like sardines to make it profitable to fly at all, and so on.
(this concept of resolving contradictions is part of 'Triz', which was developed by a soviet think tank back during the cold war, and is still championed by at least one Russian engineering company I used to work with back in the day)
1300 Mhz? do you mean 1.3Mhz or 1300Khz? (1300Mhz = 1.3Ghz, a bit fast for 1970's and Z80)
and of course 1300Khz would be audible on a standard U.S. AM band receiver.
This does bring up the point that it's not "wifi" per say that you'd communicate with by flipping RAM bus bits in the 2.4Ghz range. Modulation methods for wifi are far more complicated than amplitude or frequency modulation (think spread spectrum and QAM for 2 examples). So you'd definitely need a specialized receiver, although I expect any kind of "software radio" device would be capable of demodulating it.
That being said, there is a simple defense against this: Faraday cage. Old-style computers were metal boxen with the case relatively well grounded. Do this with a desktop computer [instead of cheapo plastic cases with metal frames] and you'll significantly impede RF transmission from the computer's motherboard. Additionally you could put metal tape and/or RF absorbing material on the inside of the case, for similar purposes. In any case, a properly designed enclosure would block RF transmissions of this nature, especially in the Ghz frequency range.
I recall a movie ('Hackers') in which a company was being threatened with a virus that would cause ships at sea to capsize, etc. etc. by flooding ballast tanks on one side of the ship and pumping dry the ballast on the other side.
So someone had at least thought up this particular 'ship-related' scenario. I'm surprised that employees of the company making the insecure ship software (apparently) never watched that movie, or at the very least paid attention to what science fiction authors foresee as a possible scenario. The movie has Angelina Jolie in it, after all... so you'd think it'd be popular amongst techno-geek engineering types!
Seriously, though, if Hollywood can predict a scenario where ships at sea (or oil rigs) being cracked into can result in extortion or terrorist plots being carried out, then software companies need to at least hire people with a mindset of watching "hacker-related" movies, if for no other reason than to get a perspective on what people that write books and movies THINK can happen, and at least prevent THOSE things from happening I.R.L..
Seriously as bad as IOT except they're multi-ton ships at sea with valuable cargo and/or potentially environmentally threatening cargo, and not just some light bulb being flashed on/off remotely (as a prank for the lulz).
when these companies are giving their stuff away for free, how ELSE do they plan on making money from it? I would assume customization and support contracts, and nothing wrong with that, really.
Just being honest up front can't hurt the bottom line, and may actually HELP it.
Yes, it seems that in Dallas, it's unusual for anyone to walk even a mile distance. I was told (when I was there on business) that it was not uncommon for people to drive 2 blocks. Seriously.
[I was there to resolve a firmware problem that turned out to be (primarily) caused by a former employee of the customer, and in a few days, we got it back on schedule - product shipped, etc.]