/tech/ - Technology★

One thing is for absolute certain, the same person will never stop making RISC-V threads on this board

The people fawning over garbage like Linux, RISC, and ARM are like medieval peasants spending the entire day tilling their fields, and then feeling gratified after mending a thatch roof so that it doesn't leak as much as it used to; completely unaware of the marvels of Roman architecture that ruled the landscape before (Xerox workstations, Amiga, Apple ][, Lisp Machines, Oberon, Multics, DISER Lilith, ITS). These are forgotten, but never can be un-created.

>>937513

Sadly that stuff's all either very obsolete or lab-grade at best. If you want to do shit these days outside of puttering around you're going to want something with a modern browser. If we could get away from the web it'd be for the best but let's be realistic.

Many people who don't want hardware backdoors are interested in alternatives. Yeah it's sad that we're not all using Lisp or Smalltalk machines but that's reality for now.

>>937513

It's hard to understand what you're trying to say when you try to argue "Apple" over (GNU?) Linux.

>>937526

Xhe's saying that there were lots of alternatives which fell out of use or failed to become more popular which would serve us well in current year, I think.

>>937526

The Apple II, not the Macintosh or or iPhone. Big difference.

>>937526

Are you unaware of the Apple II (stylized as // or ][)? It was a rather prescient computer. (Well, prescient isn't the right word; because it didn't predict the future, rather, it influenced it.) Yes -- modern Apple is evil. But, the Apple II and original Macintosh did have some good ideas.

Let's make our own computer ecosystem. I'll get started on the logo.

>>937535

The problem is actually the programmers. If your mathematical acumen is not of the level of an experimental physicist, you should watch sportsball and work a prole job -- you clearly are not fit for programming.

The instruction set of a properly designed computer must be isomorphic to a minimal, elegant high-level programming language. This will eliminate the need for a complex compiler, enabling true reflectivity and introspection at every level. Once every bit of code running on the machine is subject to runtime inspection and modification by the operator, the rotting refuse heaps of accidental complexity we are accustomed to dealing with in software development will melt away. Self-modification will take its rightful place as a mainstream programming technique, rather than being confined to malware and Turing Tarpit sideshows. Just imagine what kind of things one could do with a computing system unpolluted by mutually-hostile black box code; one which could be understood in its entirety, the way you understand arithmetic. Programmers today are shackled by braindead architectural dogmas and the market’s demand for backwards-compatibility with a 1970s traffic light controller. This scenario could have been lifted straight from a 1950s science fiction comedy. The foundations of the computing systems we use are built of ossified crud, and this is a genuine crime against the human mind. How much effort (of highly ingenious people, at that) is wasted, simply because one cannot press a Halt switch and display/modify the source code of everything currently running (or otherwise present) on a machine? How many creative people -- ones who might otherwise bring the future to life – are employed as what amounts to human compilers? Neither programmers nor users are able to purchase a modern computer which behaves sanely - at any price. We have allowed what could have once become the most unbridled creative endeavor known to man short of pure mathematics to become a largely janitorial trade; what could have been the greatest amplification of human intellect in all of history – comparable only to the advent of written language – is now confined to imitating and trivially improving on the major technological breakthroughs of the 19th century – the telegraph, telephone, phonograph, and typewriter. Brokenness and dysfunction of a magnitude largely unknown for centuries in more traditional engineering trades has become the norm in computer programming. Dijkstra believed that this state of affairs is the result of allowing people who fall short of top-notch in conventional mathematical ability into the profession.

>>937547

>not wanting hardware backdoors makes you a child

talk to a big bank or a (non-five-eyes, non-israeli) government some time

>>937549

Even Jewgle doesn't like the current state of hardware and the IME from what I heard.

>>937552

Gosh, you are right mr freetard, eevil corporations will ruin everything again, now we must make haste and complain strongly instead of doing things right. Thank u sensei for showing me way of complaining on internet while my ass gathers mold and welds itself to chair. xoxo

>>937548

>Release work under a permissive license

>What the hell? Why aren't people releasing their hardware with a free license?

Am I understanding this correctly, or am I misunderstanding the concept of Open Hardware. Because it really seems like the biggest flaw of "Open" anything, and the more neutral (but not necessarily permissive) policy it entails usually spawns two types of communities: the one who loathes strong copyleft because it de facto encroaches on the agenda of their more copyright employers whom they favor and the sort of Open Source proponents who dismiss the GPL3 as crazy but then secretly covet the share alike clauses strong copyleft imposes onto others (e.g. when Lunduke attacked the Linux Foundation head for allegedly using a Macbook).

I know this sounds incredibly biased, but I really want to understand. Software is different from hardware; even if they are conceptually related, free software is about the right to execute code, not that people have to "open" their website backend to you or show you the recipe to a dish they made--only prevent them from encroaching on your right to cook the meal. The FSF cares about website backends in a pedagogic way, much like Lunduke cares about what operating systems certain talking heads use in a pedagogic way.

>>937552

You sound worried, honestly. Like, you took all the time to type that bluster and didn't really say anything.

It's quite sad really.

>>937562

>>937578

>>937581

He actually brought up some legitimate points but you're being payed to remain on script unfortunately

>>937584

You're right. I guess all those billion dollar smartphone manufactures that are wildly more successful and smarter than you sure look stupid now.

>>937587

What a non-sequitur. When Jews A clearly no nothing but the Jews that appeal to your autism, yes, those are the trustworthy guys that know what they're talking about. Why are you even defending smartphone chip makers all of the sudden? I thought RISC-V was meant to avoid that bullshit. Can;t get your narrative right can you?

>>937593

These are the kinds of people that want you to buy 1000 dollar RISC-V boards. Never forget

>>937550

That's why they added secret out-of-band chips to all their chromebooks, right?

>>937571

>Jonathan Neuschäfer also commented on that thread was a SiFive comment that they are not able to provide the initialization sequence for the DRAM controller. SiFive suggests reverse-engineering / disassembling the binaries for this data.

This is fucking disgusting and yet at the same time the type of behaviour which was predicted SiFive would display in the massive OpenPower vs Risc-V shitfest thread we had a few months ago.

What likely happened though is SiFive was more interested in the cred and in their haste to signal their virtue of being the first commercially available Risc-V SoC they decided to license IP from third party vendors. They posted their work on github but what they did is all the easy stuff like the basic peripherals (ie, stuff which is easy, especially with chisel). For the more complicated stuff, like the memory controller, they most likely licensed the module from a third party which is why they can't release the source code for the initialisation or the documentation.

>>937571

There are really two levels of "Open Hardware", one where the manufacturer releases documentation which describes in detail how the hardware is structured and works, and the other where the source code for the actual hardware is released. The first allows for the development of open source drivers and such can be as full featured as drivers developed by the manufacturer, and the second allows for the first as well as for third parties to make clones or modifications/upgrades of the chip. For the vast majority of people just having the documentation is good enough, because with the documentation I can verify that there is nothing hidden (read: malicious) on the chip and for the people who actually have the skill to design ICs and the means to get them fab'd its enough to make a clone anyway.

Its like buying a car and being given a instruction manual and a highly detailed repair manual with it, most people would be happy but a tiny minority of autists will complain about how they deserve to be given a full set of blueprints as well.

>>937639

It's like that but different, imagine that some autists notice the car is driving itself across town and being used by a pimp as a mobile prostitution shack, but the car comes back at night, so those autists are now suspicious about things and want the whole blueprint.

Because that's where we are with computers now.

>>937639

>just having the documentation is good enough, because with the documentation I can verify that there is nothing hidden

It might not be complete documentation though. There still might be hidden functionality.

>>937523

>>937526

retards don't talk to the eternal lisp fag

you'll get nowhere

>>937548

W-we still have lowrisc.org r-right?

>>937535

You should perhaps look at what is happening right now on big ARM chips. They are starting to show symptoms of ME PSP.

How will RISC-V not have the problem that the main manufacturers start shoving this shit in to soon after it's start ?

>>938048

It's literally required by the secret laws passed post-911.

>>937800

At least with RISC-V, anything compiled/optimized for it right now can run on later fully-libre versions.

>>938080

Source?

>>938211

>>937800

What about nanomachines (talking 15 years into the future at least) that print the circuit on a pre-made silicon die?

>download GNUarch.tgz from gnu.org/hardware

>untar, ungunzip, send to local hackerspace microprocessor die printer

>proceed to run Super Tux Kart at 144Hz and graphics set to "ultra" on your new Trisquel freedom machine

>>938241

>nano machines

3D printers can already print silicon now.

>>938263

Yes, but they can't print the circuits on it. There's more to a microprocessor than the silicon die.

When we have the dictatorship of the proletariat

>>938313

This

You know it really doesn't matter what architecture is used. If you don't want backdoors we need individual components to be open source and then some manufacturer to slap that together on a board.

Also the removal of secure boot and all of those "trusted execution" engines they slap into the cpus.

Also coreboot by default.

x86 is horrendously complicated and I don't agree with making the cpu complex so the compiler can be simple, because what we ended up with is both are extremely complex.

ARM could easily beat RISCV right now by open sourcing their gpu hardware and booting process.

But they won't because if they ever allowed Linux to get good open source drivers then they wouldn't be able to license out so many shitty sbc's with broken firmware just so you and I can buy one in the hopes it will be mainlined enough when it invariably isn't. All we're left with now is the raspberry pi, which is woefully under-powered .

It's somewhat ironic to me that people are trying to push everything into SaaS and Cloud based computing that they still feel the need to run power hogging x86 with their 500w PSUs. Wouldn't we only need thin clients? The fact that our web stack is so broken that SaaS literally requires a super computer to churn through all that shitty js code means we haven't arrived at the future and in general almost no one knows what they're doing as far as manufacturers go.

Intel doesn't know what it's doing, they tried to pimp the architecture so hard for speed they got bit in the ass with security problems.

AMD is the same.

ARM won't get it's head out of it's ass and take advantage of the situation for the desktop market.

RISC-V is taking forever and doesn't really offer anything over being "clean"

POWER is expensive as fuck

All the others are pretty much dead.

Software is causing the problem.

The shift to tablets/phones on crufty towers of android and ios stacks is causing the problem.

The philosophy of compilers and CISC is causing the problem.

The false shift to SaaS is causing the problem.

In other words, we're completely fucked at the moment.

>>938238

>source for secret laws

Simple observation of the effect of these laws on the CPU industry.

>>937639

>>937800

>>938393

>Muh auditable hardware

http://www.loper-os.org/?p=2433

>Yet, unlike Intel, Google --- in its fetishistic pseudo-openness — appears to have published at least a portion of the source for the device’s firmware

>So, back to the Cr50: this device appears to be present in all of the currently-produced Chromebooks, and is --- per the vendor’s published source — able to rewrite all firmware, under the control of an external debug snake, or other, yet-undiscovered triggers; start and stop the CPU; master the I2C bus, on which, among other things, are to be found the sound card’s microphone; upgrade its own firmware; and other interesting things that may or may not align with the machine owner’s wishes at a particular moment. Possible usage scenarios include, but are not limited to, enablement of “lol enforcement” surreptitious searches and buggings of “borrowed” machines (and this is merely one obvious scenario.)

>Got the key? reflash to your heart’s delight. No key? no update. Just like in other “Tivos”, e.g., the Apple iPhone, but in this case with an extra helping of Open Sores artificial flavouring!

>>938393

The features of secure boot and trusted execution isn't inherently wrong. The problem is that the users who own Intel and AMD computers are not allowed to control these features because users are not allowed to control the technical keys that are the key to these features. This implies that when users are allowed to control the keys, users will have control of the computer.

>>938610

The problem with these technical features is that it would be extremely difficult to implement them in a way which would be trustworthy. There is always the possibility of the manufacturer including extra functionality which is undocumented for their use only, backdoors, etc. Especially in this age when so much of a CPU's functionality is bound to its microcode.

>>938619

If you look at the post I was referring to, you'll see the context is about a computer with "open source components"; I would include the CPU as a part of that. If you cannot trust your manufacturer to implement secure boot according to the open design specs that are widely and publicly available, then the existence of secure boot and trusted execution is irrelevant for that CPU; you cannot trust any part of the CPU to have no intentional backdoors.

>>938393

>It's somewhat ironic to me that people are trying to push everything into SaaS and Cloud based computing that they still feel the need to run power hogging x86 with their 500w PSUs. Wouldn't we only need thin clients?

But that's exactly the direction things are going. Only people who need to power a fast video card or CPU (or both) have machines with 500W+ power supplies. The rest are moving to phones*, tablets, Chromebooks, and other laptop/minilaptops.

Even your standard office drone isn't geting a tower PC anymore, but an all-in-one that probably draws less than 200W. Less than 125 if she's not streaming the latest hit from [insert pop star here] on Jewify.

For the foreseeable future, people who do software development, or make multimedia, or play games will still need big machines. It's becoming more of a niche, though.

*And keep in mind that the only reason that the "% of the population with Internet access 'at home'" is at high as it is is because of the legions of poors with Obongophones and a dataplan. That's the only computing that segment of the population does.

>>938585

Who cares? You can reflash it.

>>938661

<who cares that you can't remove NSA backdoor

>>938661

>the machine owner cannot simply remove or cut the traces to the Cr50: it has been placed in control of power supply bringup; the valuable debug interface; and other essentials.

I want at least a fucking rpi-like riscV board when enough support that I can use without worrying if its backdoored like the actual rpi is

Same CPU could be use to build a truly libre phone that can replace current botnet models

Also you could build a modest linux laptop with it, tho I would want a bit more power for that

>>937513

Nigger you realize those machines are mostly 40-50 years old right?

>>938048

Pretty sure all ARM chips have been compromised for years now

>>937800

>Most of us are not likely to be so important to be affected by such a sophisticated piece of software, though

This shit is getting automated, and governments build datacenters to store all your shit. You might think its nothing but one day you could be in a position where someone wants to fuck with you. Could be a fucking low-key government employee with security clearance (millions of those) who can access that DB and see you been fapping to pony scat porn or some other embarrassing shit and use that to blackmail you. This shit used to happen a lot in commie police states where stasi faggots would go on power trips and ruin random peoples' lives by using their state files against them.

If I had "fuck you" money, I would sponsor the shit out of lowrisc.org, and as a side venture, sponsor those pasta niggers trying to build a laptop with a nxp powerpc as well.

>>939656

There was nothing on ARM like there has been on x86 like Intel ME. Maybe that's changing, but he didn't even say which "big ARM chips", or "what is happening", so that's an empty statement. It smells like FUD.

The biggest revolution would be chips that we can realistically make ourselves and guarantee aren't Jewed.

>>937796

You want to know whats actually scary? even if you had the RTL and the mask files verifying that one matches up to the other is a monstrous task as even low end desktop CPUs have billions of transistors and use dozens of metal layers, just because they are released by the manufacturer doesn't mean that they are connected. And even if the RTL and masks released by the manufacturer match doesn't mean they are the ones used in production, to verify that you would need to scan every one of those billions of transistors with an electron microscope and check that they match up with whats expected.

>There still might be hidden functionality.

If you have the datasheet you can check with pretty good certainty if there is extra stuff, in the same way that those white hat hackers mapped all the hidden instructions in x86 by cycling through all the possible instructions if you know what hardware your chip should have you can cycle through all the possible memory addresses and record any which aren't documented.

Also you don't always need the full documentation to be sure its botnet free, for instance due to trade restrictions Intel and AMD can't sell x86 CPUs to governments like China which is why they buy Power8/9 systems. If the Chinese government, who you can be sure as hell checks their systems for backdoors with a fine tooth comb and has the resources to make their own chips if they wanted, is happily buying them then its probably a safe bet that they are botnet-free.

>>939707

ARM has TrustZone which performs roughly the same function as Intel ME and AMD PSP.

>>938393

>POWER is expensive as fuck

Its expensive because autistic memelords would rather spend $999 on a shitty Risc-V SBC (with no display output, no PCIe slot, missing essential instruction set features like vector extensions, and requiring binary blobs) over a high performance single socket Power9 mobo with 4core/16thread CPU for only $500 more. So long as Power9 remains boutique it will be expensive, the RPi didn't get to its current price point overnight, it got there by being popular enough to be produced on scales large enough to squash the price down.

>Software is causing the problem.

>The philosophy of compilers and CISC is causing the problem.

This is true to a large extent, hardware development has basically stagnated for the last 20 years because the average software developer is a fucking moron and everyone who can make a difference is too lazy to do so. Every performance gain when it comes to CPUs and such has basically been hampered because any change can't break the performance of existing programs, so all we get are tiny incremental improvements.

If people were willing to throw out basically everything, hardware paradigms, existing operating systems, and sacrifice the performance of existing programs, and start from scratch then computers could probably be an order of magnitude faster than they currently are.

>>939730

> TrustZone

That's basically the equivalent of TPM on x86. It's got nothing to do with Intel ME.

>>939734

Intel ME started off as the management for the trusted execution environment, same with AMD PSP. TrustZone has slowly been extended just like PSP and ME were and like them it also has access to everything without the main processor knowing. They are all hardware and code which operates at lower than ring-0.

>NEVER EVER

>NEVER EVER

>NEVER EVER

<NEVER EVER

>>939737

But nobody would have a problem with x86 negative rings if it had stuck to TPM and prior stuff like power management. The reason people are pissed is Intel shoved a complete remote sysadmin environment into their hardware, that only the cianiggers know how to disable across all modern chips. It was originally "sold" as a tool for sysadmins of corporate networks, but then ended up into every single chip Intel chip made.

That's the big problem, not the fact x86 can do power management or DRM. Well that and the fact that x86 is the fucking swiss cheese of bugs.

ARM TAKES DOWN ITS ANTI-RISC-V PROPAGANDA SITE AFTER BACKLASH FROM ITS OWN STAFF

https://www.theregister.co.uk/2018/07/10/arm_riscv_website/

http://archive.fo/qNjte

>>939750 on suicide watch

>RISC-V desktop when?

Apparently

NOW

https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-board

>>941149

Thats just a FPGA dev kit they slapped a RISC-V logo on. There isn't a RISC-V ASIC on there, you implement it on the FPGA.

>>941147

If ARM wants to kill RISC-V, they should make ARM FOSS and charge consultancy fees.

They would probably make more money this way.

>>941154

I was implying that you can use that to make a desktop out of your FPGA.

>>937571

>when Lunduke attacked the Linux Foundation head for allegedly using a Macbook

>allegedly

He literally did a presentation about linux on a macbook running appleshit and was seen by a kernel dev using an apple tablet.

RISC-V is permissive but the RISC-V foundation won't certify or allow you to use their trademark(RISC-V) if you break their spec, proprietary extensions are treated separately, if a chip vendor breaks how atomics or compression works RISC-V will not allow them to advertise or say they're using RISC-V hardware.

>>941149

>>941157

You're both wrong. It's an expansion board for the HiFive unleashed, which does have a custom RISC-V processor, the "Freedom U540". Performance is terrible, mind you - both board together cost $3000 for less grunt than a Raspberry Pi. The processor is not fully open source either, but it's a start.

>>941221

>compression

>RISC-V

So it's CISC?

>>941959

Nope. It's an open extensible RISC ISA, with a number of official open extensions, and provision for private custom extensions.

>>941221

Oh, absolutely. We can totally trust the testimony of a fractious Debian developer who's been a source of contention before his accusations and no tangible photo evidence.

>>938393

>x86 is horrendously complicated and I don't agree with making the cpu complex so the compiler can be simple, because what we ended up with is both are extremely complex.

RISCs are designed for C and UNIX, which means they make everything else slow even if we knew how to do it fast for 50 years. CISC features like like segmentation and powerful instructions are discouraged in x86 today and most are banned in 64-bit mode. The bloat in x86 is from SIMD instructions and the other bullshit they keep adding, not from CISC. The "complex" in CISC means the instructions themselves are complex, i.e. they do a lot, not that there are a lot of instructions or that it's complicated to use them. Branch delay slots and multiply-step instructions are RISC. POWER has a lot of instructions but they're all RISC instructions.

>It's somewhat ironic to me that people are trying to push everything into SaaS and Cloud based computing that they still feel the need to run power hogging x86 with their 500w PSUs. Wouldn't we only need thin clients? The fact that our web stack is so broken that SaaS literally requires a super computer to churn through all that shitty js code means we haven't arrived at the future and in general almost no one knows what they're doing as far as manufacturers go.

All of that could be much faster and use much less RAM, while having more features. Even the "thin clients" are powerful enough to run a real OS (better than UNIX) with real software. It sucks how wasteful everything is. They don't care if their software sucks, whether it's bloat, crashes, exploits, or lack of design. These are all symptoms of the same problem and the root of why C and UNIX suck. They don't fix ls or bc or any of those other broken shit "tools" because they don't care if they're broken. They don't replace null-terminated strings because they don't care if strings are useful.

>In other words, we're completely fucked at the moment.

Things will only get better when C shills can't push around hardware designers. C sucks so much that C weenies are still worrying about errors caused by integer overflow, a problem solved in the 50s.

>>941147

Most of the good comments have far more downvotes than upvotes, even though they're all factual and accurate.

>Bruce Hoult

>I find it amusing that my perfectly factual post ... and from someone helping design RISC-V CPUs and working on RISC-V compilers to run C fast ... got 30 downvotes here. Apparently a lot of people are half-educated. Oh well, lol etc.

   Hey. This is unix-haters, not RISC-haters.

    Look, those guys at berkeley decided to optimise their
chip for C and Unix programs.  It says so right in their
paper.  They looked at how C programs tended to behave, and
(later) how Unix behaved, and made a chip that worked that
way.  So what if it's hard to make downward lexical funargs
when you have register windows?  It's a special-purpose
chip, remember?

    Only then companies like Sun push their snazzy RISC
machines.  To make their machines more attractive they
proudly point out "and of course it uses the great
general-purpose RISC.  Why it's so general purpose that it
runs Unix and C just great!"

    This, I suppose, is a variation on the usual "the way
it's done in unix is by definition the general case"
disease.

>>939695

>lowRISC is creating a fully open-sourced, GNU/ToyOS-capable, RISC-V-based SoC

>SoC, "fully" open-sourced

>GNU/ToyOS capable

it's trash.

>>942747

32-bit microprocessors running 32-bit operating systems can use 64-bit time stamps which make the Y2038 problem irrelevant.

>>942772

That's nice qt, too bad they mostly don't and people will install Debian on these which still has an infinite number of 32 bit time issues on i386.

>>942750

>GNU/ToyOS capable

>Trash

Would you rather have it be incapable of running Gnu/ToyOS?

>>942747

> Oh no, it's retarded.

The RISC-V spec defines at least one 64 bit clock on all of those

>>942860

That's nice qt, too bad it's a software problem.

>>942777

>on i386

>>942910

You just have no clue at all. There is 64 bit time on i386, the problem is all the software using the word size as time. Same problem on RISC-V. It will be a massive undertaking to fix, meanwhile IoT devices on RISC-V 32 that will exist in 2038 are headed out into the world. They fucked us hard by supporting 32 bit.

>>942930

>use wrong data type

>because who gives a fuck what the manual says

>stuff breaks

No shit sherlock.

>>942930

So what if it takes a lot of effort to fix? The cost of fixing all those libraries and software now is much smaller than throwing away literally everything that touches 32-bit time and writing new replacements that does exactly the same functions except with 64-bit time. How many years is it until 2038?

>Could the catalyst for mass adoption of RISC-V be driven by China and India?

https://www.eetimes.com/author.asp?section_id=36&doc_id=1333476

India and China are now at the forefront of technological innovation. Stupid amerifats getting fucked over by trump

>>943966

>forefront of technological innovation

>still shitting on the streets

>>943971

>butthurt about America turning into a shithole

>comes up with poo in loo jokes

S E E T H I N G

>>942708

What about this? https://groups.google.com/a/groups.riscv.org/forum/?_escaped_fragment_=topic/sw-dev/esYoby-4_GU

>This group will be responsible for proposing RISC-V extensions for managed, interpreted and JIT-ed languages that have extend beyond those of ahead-of-time compiled Algol-family languages (such as C/C++).

>The RISC-V J extension aims to make RISC-V an attractive target for languages that are traditionally interpreted or JIT compiled, or which require large runtime libraries or language-level virtual machines. Examples include (but are not limited to) C#, Go, Haskell, Java, JavaScript, OCaml, PHP, Python, R, Ruby, Scala or WebAssembly.

>Typical features of these languages include garbage collection, dynamic typing and dynamic dispatch, transparent boxing of primitive values, and reflection.

It will be a standard extension, but still WIP. I was reading the RISC-V spec and found the placeholder chapter for it. That mailing list was the only thing I could find.

>>943966

They want the same thing to happen to hardware innovation that POSIX did to OS innovation. They want to set the standard for ISA and they compared it to POSIX, C, SQL, and OpenGL. There's a presentation about that. RISC-V was created to port GCC, glibc, and Linux. New computers before RISC were created to reduce the amount of code necessary to do something compared to older machines. Since RISCs were made to port C compilers and UNIX instead of writing a new OS and compilers from scratch, reducing the amount of code wasn't helpful for them because they would have to do more work to take advantage of the new hardware features.

>>946642

Right now, it's vaporware. Maybe it will be good, maybe not.

A fine suggestion from the authors of the tla tcp for vms
documentation

>
>Unix	(you-nix) Another operating system that lots
>       of people use.  People who use Unix tend to act like
>       they should set the standards for everyone else.
>       If you meet someone like that, you should hit them
>       with a wet fish, apologize, and then pretend nothing
>       ever happened.
>
>VMS	(vee-em-ess) The operating system of the future
>       which will probably be extinct in a few years.
>


Personally I would leave out the apologize part.