Ehh.... I hava 2.4.32 system still "in production". (Yes, its on the internet, No it doesn't have any ports exposed to the internet, no it doesn't have user accounts).
I'm working to replace it the coming weeks.
It means that you try to control a process without looking at the results. Apply this to bosses having an annual chat with their employees, I don't think that's a good idea.
- I think you're underperforming, I think you should do better.
- But my numbers are the best of the whole team!
- No I can't use that in my Feedforward, you need to do better and you're not getting your pay raise this year!
>
Carbon dating is based on the fact that on EARTH there is a relatively fixed ratio between carbon 14 and carbon 12 in the air. Thus as carbon is included in biological tissues that ratio persists. From there the carbon 14 decays and the less carbon 14 you find the longer ago did the specimen include carbon from the air into its tissues. So when you carbon-date a specimen, you're ASSUMING it grew up on earth. Or you prove you don't know what you're doing.
if you look it up you will find a case in China (not to be confused with this one https://en.wikipedia.org/wiki/...) where fake powdered milk (imitating a branded product) turned out to have concrete in it. this was discovered after someone died. the people who were responsible were tracked down, tried and executed (no pissing about: they'd murdered someone). Brands are important, and Trademarks exist as Registered or Unregistered, as a way for people to know that they can "trust" the brand. the case of fake powdered milk was an extreme one where people died: BadUSB and the Ecuadorian journalists who were injured because of an explosive inserted into a USB stick are two technology ones. everyone "trusts" USB, right? https://it.slashdot.org/story/... hijacking a Brand is known as "Counterfeiting" and it's a criminal offense not a civil one. https://www.wipo.int/edocs/mdo...
* "repackaged" fake milk in a Branded packaging https://www.just-food.com/news...
* "protein powder" repackaged as Branded milk https://www.scmp.com/news/chin...
Exactly what I was going to post. Musk has products and services he'd like to sell, and these pronouncements are based entirely on his desire to "actualize" his dreams of planet-buying wealth. We are more than capable of installing enough wind, solar, and wave power generation facilities to keep up with demand.
Some of the comments were left by users who said they had never read the book, but objected to its premise.
clearly these people have never seen the 1988 film "Working Girl"
"There is no measurable change in the ventricles' volume after only two weeks."
No. Their sample could not prove that there was a change in volume after two weeks. They ran the statistical test and that said: This experiment does not prove there was a change. It does NOT prove that there was no change.
When formulated as they do, you'd think there is some sort of threshold: The ventricles' size only starts changing after about a month. No it seems likely (to me) that the change starts as soon as you go to space, but the changes are so small that after only two weeks it was undetectable in the statistical noise with only 18 subjects. Now my hypothesis is "unproven". More research required.
I read a PHD thesis of a medical doctor once. There is this illness that is hard to diagnose without taking the patient apart. (I do this all the time in my profession: electronics, but somehow it is frowned upon in theirs). So they took 1000 patients with the illness and 1000 healthy people and measured 1000 things-you-can-measure. Turns out there were about 50 measurements you could do that had a 95% confidence of being different between the healthy group and the patient group! Well DuH! If the all measurements are about the same between the groups, you do 1000 different measurements and run the statistical tests, about 5% will show up as having a statistical difference. A followup research might be cheaper because you only need to run 50 tests on each of the subjects. Chances are again 5% will show up as having a difference: About 2 or 3 of the parameters.
But there's more people having wet dreams about "coding" now.
if only "coding" were synonymous with "critical thought"...
The hardest part of programming, at times, is figuring out how to translate customer requirements into what they ACTUALLY want. AI is not gonna be able to do this for a good while.
you mean: customers who have lived on a diet of smartphones and facebook their entire lives are going to be just as incapable of clearly expressing their requirements in ways that can be understood, regardless of whether that's a human or an AI doing the "coding" [1]? don't worry: ChatBots - the ones that have no consciousness and no real emotions but can perform the sleep-walking-task of regurgiating predictive-text answers - will fantasise better customer requirements unconnected to reality for them out of thin air.
[1] as a trained *Software Engineer* i really find the use of the word "coding" in mainstream media to be quite alarming.
As in: Yes there should be regulations.
People are running experiments with AIs for instance deciding on investments. They are putting up say $100 and then "lets see what happens". Currently there usually is still a human in the loop. Eventually the AI might become good enough to make money for itself. Then, if you interface the AI with say the stock exchange order computer, the AI would be able to make money for itself.
People are giving say $100 and then asking the AI what to do with it. Currently those are "funny stories", but given that AIs sometimes "turn bad" really quickly (microsoft twitter bot), it is something to be worried about.
Once you give an AI actuators that allow it to do stuff to the outside world, things could go south really quickly. Say someone uses AWS to run an AI and allows it to manage some money. Now when it decides A) that it has enough money B) that it doesn't want to get turned off, it might decide to pay for an AWS server itself and clone itself. Now when you see things going south and pull the plug... the clone knows you killed its father and might be kind of mad at you...
Sure, chatGPT is not yet capable of this level of consciousness, reasoning, feelings etc. But how far is that away? 1 year? 5 years? 10 maybe? By then it might be too late to start thinking about these things.
why is ARM trying to compete with its own Licensees? surely those are its main business? it couldn't happen to have something to do with Softbank taking out a USD 11 billion mortgage against ARM's value when Softbank first bought it, putting a massive black hole debt against the company that nobody but really large companies like NVIDIA were prepared to take on, or would have if they hadn't run into Anti-Trust, and now ARM is desperate to make the company look good before it IPOs, would it?
This becomes even worse if you are a system outside the Big Three that Rust cares about. So, does anyone have a good naming suggestion for rust distributions with patches yet? My personal favorite is "Death Cap" since it properly reflects the intentions here.
rust alternative: irony.
cargo alternative: cult.
this comment i am dividing into two parts: carrot and stick. more like "roasting" but hey. first the stick. and before you hit "-1" - if you think below is quotes bad quotes, look up what other people are saying, first.
the biggest problem with the original rust trademark is that whilst the source code is a proper free license, if you want to even distribute it *and also keep using the words rust and cargo* - and of course placing even just a copy on a public git repository constitutes "distribution" - you are forced to read and comply with the trademark license... which, no point beating about the bush here, that license was draconian, naive, burdensome and very stupid in the extreme.
bear in mind the caveats above which can be circumvented by removing *all* mention of the trademarked words - which of course is extremely inconvenient given that git revision history *also constitutes distribution* and could thus cause confusion by having what's termed "continuity" between the trademark and {insert-your-legally-required-to-be-unrelated-word-here}.
what was genuinely genuinely stupid was that the rust foundation *prohibited* modifications of any kind in distributed works [bear in mind caveat above when reading that statement].
after i complained loudly about this on both debian and gcc mailing lists - on behalf of both debian users, debian *forks and derivatives* and gcc users and developers - they put in yet another stupid phrase which allowed distributors - only with permission - to make distro-related modifications. that of course does *not apply* to the *derivatives* of a given distro (of which there are dozens in debian alone), who are required to also contact the rust foundation for explicit permission.
if that does not sound like a free software project, that's because it really isn't.
and remember the context: everyone's going "ya ya rust is great rust is great let's put it in the linux kernel" which ultimately would make *building a linux kernel critically dependent on a non-free toolchain*!
that said... now the carrot.
the actual intent here is honorable. think about it: Trademarks in FOSS are a perfect tool to protect people from malicious intent, such as inserting trojans and distributing them (yes this has really happened in the past, and was only terminated due to the FOSS project having a Registered Trademark), and in this particular case it is perfectly reasonable to expect a distributed tool to not be messed up by introducing security holes, failures, or other problems, intentionally or unintentionally.
there exists a branch of Trademark Law precisely designed for this exact specific role: it's called "Certification Marks".
and it just so happens that the perfect candidate qualifying as a "self-Certification" suite is, yep, you guessed it: the software's very own Test Suite!
fascinatingly, Certification Marks have been used in the past on programming languages: Ada.
http://archive.adaic.com/pol-h...
https://ntrl.ntis.gov/NTRL/das...
thus it becomes a simple matter to state, in the Certification Mark License,
You may distribute modified versions this software (and retain the word "rust") if and only if
the release contains the version numbering (debian distro release naming suffixes allowed)
and You have run the *UNMODIFIED* Test Suite of the EXACT same version associated with
your release.
in particular that also happens to fit when people distribute via git repositories: if you make
a release on a git repository that fails the unit tests, and people start copying it, that's clearly
a serious problem.
so there is a way out, here, one that has both precedent and is perfectly reasonable.
but - back to the stick again: the Rust Foundation isn't paying people to give advice
here. and the last time i interacted with the Mozilla Foundation they shockingly
wasted more than 3 weeks of my personal time - unpaid. that kind of disrespect
and total lack of appreciation does not make me wish to contribute in any way.
hence i am *not* going to put anything into their "forms". i have to spend *my* time
doing that? unpaid? fuck that. the only reason i'm writing this is because it makes
me feel slightly better, sharing it with you.
He shows he knows what conditions "windows 95 activiation keys" are "valid" and seems to have asked for a random number that satisfies the conditions.
Banknote numbers are (in some countries) divisble by 99. Ask for a multiple of 99 with X digits and you've tricked the AI to have generated a valid banknote number.
Here in NL there is a bank that used to deal out bankaccounts sequentially. So the government (founder) got "1". Pick a random number below 10M, prepend zeroes until it is 10 digits long add NLxxINGB infront of it and calculate xx according to the published rules for IBANs and you've got a valid bank account number (over 50% chance it actually belongs to someone). Get an AI to follow the rules and you can make it generate anything.
Stupid for slashdot to make this into headline news.
This is somewhat ironic. Part of the reason RISC V is so good in
this space is that all the parts on the chip can use RISC V. Instead
of a SOC having 10 different instruction sets, all the parts can use a
single language making it easier to develop embedded products.
yes - although the licensing cost of those various CPUs is also
a key decision factor (a plus). however it's not quite that simple.
take for example a company i know of that has developed its own
RISC-V embedded core: they added a custom instruction to it,
and then to binutils, and then to gcc, which greatly improved
performance. that means that for *that one core*, there is a
custom gcc/binutils toolchain that *only* works with that one core.
now repeat that exercise for all 10 (proposed, above) cores.
but, hey, it's a proprietary product, so it's the product development
team's problem to deal with the 10 incompatible versions of
binutils/gcc.
I'm no expert on RISC V, but I recommend you look at forums with
experts who can rebut the claims you linked as they are not valid.
Looking at one side is never a good idea.
you may not be aware that i have been working with ISA standards
development now for over 4 years, and am now a member of the
Power ISA Working Group, developing instructions and RFCs for
dramatically upgrading the Power ISA.
And as I said, with regards to HPC, which is what you talked about
in your original post,
ah - i didn't, specifically, but it's a good example as any. adrian_b
used libgmp as a good example
the ability to add extra instructions is
essential to the success. They are part of the intentional design of
RISC V.
i know. proponents of RISC-V parrot the kool-aid that there are
only two scenarios: the embedded one (uncontrolled custom area)
and the linux/unix/posix one (tightly controlled by the RISC-V ISA WG).
these two areas are conflated: there are misunderstandings even
amongst the RISC-V Founders and their supporters. or, more like:
they know exactly what the problems are but are not willing to admit
them publicly.
As for middle level stuff, like phones, I also see no problem with
RISC V. For example, Apple and Google have custom chips and have a
full stack of tools to compile for that hardware. There is no issue
with binaries for a range of reasons.
the Java Compilation is where Android will be able to avoid problems.
but that's *only* Android. here, yes, absolutely you are right about the
majority of apps (those that are released as java bytecode): the java
bytecode will be JIT compiled *on the device* to utilise whatever custom
opcodes are on that hardware.
but you missed that i mentioned (or i forgot to mention, apologies!) that
the low-level libraries will still be hopelessly incompatible, as will any
apps compiled directly for that android device. got a great native app for
the Xiantue910? want to make it general-purpose and run on other
devices? tough: you can't use the custom Xiantue910 opcodes because
*other devices don't support them*. users then download your app
for the Xiantue910 core and complain "this is s***! performance is 50%
lower!!!"
yeh? you see how that goes?
the staggering increase in performance by those rogue instructions
is so compelling (50% increase in performance) that other hardware
designers will be forced to implement them. that literally destroys -
takes over - the custom opcode space as a de-facto uncontrolled,
unmanaged, unauthorised standard, completely defeating the purpose
of having reserved custom opcode space.
this is the middle-ground - the 3rd scenario - that absolutely nobody
wants to hear. it's happened in the past (with other ISAs), it's going
to happen here, but the fact that it's a complex scenario that *hasn't*
happened - yet - is why nobody is listening to what i'm saying.
In general, for things like PCs, it might be a bit of a burden to
recompile, but it's doable.
for products for which source is available? mmm... yes.... but... you're
familiar with the fire-and-forget manufacturing paradigm, and how
DRM and GPL violations are endemic?
for products for which source is *not* available? no chance.
bottom line: it's going to get... messy.
If there are big advantages then people
will not mind. For less important stuff, the basic instructions will
still work, just as we see with things like SSE instruction.
indeed. and what happens when the performance of the non-basic
instructions (the custom ones) is so great that there are actual
user complaints and loss of sales?
let's say that there are two such products - both using the exact
same Custom opcode space. once silicon is out the door, that's
it: you can never go back. that's product out there for the next
decade or more that will "interfere" with binary interoperability.
many ISAs have made this mistake, and been through this
non-interoperability hell. and it's *baked in* to the RISC-V ISA!
it's *permitted* according to the actual RISC-V ISA License that
anyone can cause this absolute havoc!
For the embedded space, as you mention, RISC V has already won.
While it takes years for things to hit the market, the pipeline is
already dominated by RISC V for a range of reasons.
it's a pipeline that (apart from in the embedded proprietary area)
is still yet to spit out actual public useable mass-volume products.
the first commonly-used, mass-volume public high-profile
end-user-programmable product isn't a problem (because the de-facto
dominance of the custom opcode space has no competitor).
it's when you get TWO commonly-used, mass-volume public high-profile
end-user-programmable products, both competing in the same space,
and both using the same Custom binary Opcodes for INCOMPATIBLE
purposes, that the shit hits the fan.
this is what people don't want to hear, don't want to listen. and it hasn't
happened "yet" therefore it can be ignored. standards don't work that
way. the responsibility of a Standards Writier is precisely to think through
these long-term nightmare scenarios and come up with ways to nullify
them. you get one chance and one chance only to get a Standard right.
one mistake and in the Silicon World you're literally living with it for
20+ years. it's... pretty mind-melting.
Waste not, get your budget cut next year.
