Comment Re:FIPS Validation (Score 1) 66
Just to add, for this reason I'm only helping out with the C coding, not leading the effort
Just to add, for this reason I'm only helping out with the C coding, not leading the effort
It's a fair cop
Yeah, it's important for customers though.
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"
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.
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.
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.
It's also ill-informed about HPC. It's the easily extendable
instruction set of RISC-V that makes it a win.
only in embedded products where compatibility and interoperability
is completely unimportant. a classic example is the Trinamic Stepper
Motor Driver ICs that adopted such an early version of RISC-V that
the standard hadn't even been ratified yet, but it in absolutely no way
mattered because the compilers worked, binutils worked, they could
*PRIVATELY* make as many custom modifications as they wanted,
shove the binary into metal masks and absolutely nobody would know.
in this situation (private, custom, secretive, proprietary usage) you
are absolutely right: there is absolutely no problem whatsoever.
if you try that with the custom opcode space and you're publishing
binaries that are expected to be interoperable (native Android apps for
example) then you're absolutely screwed. or, more to the point, you've
screwed the custom opcode space for absolutely everyone else: you've
basically "de-facto dominated" those opcodes because they're no longer
available for anyone else:
* anyone (any silicon) *not* implementing those custom opcodes will have
binaries that are incompatible.
* anyone implementing OTHER OPERATIONS using those exact same
custom opcodes (and also publishing public binaries) is in real serious
trouble.
* where it gets even more serious is when a programmer wants *BOTH*
conflicting - public - custom opcodes in the same binary (because the
features of the publc custom opcodes are so important to speed or
power consumption that they're absolutely necessary to the software).
it's a total mess in other words, that needed to be planned for well in advance:
to provide proper conflict resolution. and that simply hasn't been done.
there is an train-wreck coming, and it's going to take several more years
for that train-wreck to occur, but it is unfortunately already unstoppable.
It will take decades, but RISC-V is the future of instructions sets.
no, really, it isn't. read this - it's the best independent analysis i've encountered which
outlines the problem:
https://news.ycombinator.com/i...
summary: the over-simplification of the RISC-V ISA comes with a price:
larger binary size and greater hardware complexity to compensate. RISC-V
advocates claim that "Compressed" compensates compared to other ISAs
(it doesn't: adrian_b explains why).
what *will* take several years is for "everyone expecting optimal-performance
hardware to turn up" to realise what that person (adrian_b) is talking about.
what's actually happening is that large organisations betting on RISC-V in
high-performance are being backed with extremely large grants and large
investment, only to find that RISC-V cannot deliver. the problem is that the
committment in terms of funding and time to get to an actual ASIC is so large
that they can't back out.
to illustrate: the only reason that the Alibaba Group's Xiantue910 could claim
better performance than a high-performance ARM Cortex A73 was because
they added FIFTY PERCENT more Custom (rogue) instructions to the RISC-V
ISA.
oink.
by complete contrast, in the *low-end* embedded arena where the binary
size is immaterial vs the cost of licensing an ARM Cortex M0/3/4, RISC-V
is taking the world by storm, because zero royalties is unbeatable.
what i heard from someone who has experience with infections is that the human body immune system goes into such complete fanatical overdrive when first detecting any infection that any *new* infection is obliterated. what Richard Webby is saying seems to concur with that [simplistic] perspective.
what the person also told me is, if you *do* get more than one infection at a time, it's because you're dying (basically). your body - including your entire immune system - is shutting down.
the bit that's new to me is that Foxman's team appears to be saying that the actual *viruses themselves* tend to clobber other viruses, which is really very interesting.
All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin
