When will it die already?
Shit no one needs/wants
Other urls found in this thread:
en.wikipedia.org
man7.org
qmonnet.github.io
marc.info
en.wikipedia.org
github.com
github.com
appleinsider.com
theverge.com
github.com
twitter.com
15 or 20 years ago people were super excited about new shit, both hardware and software. New shit meant significant new improvements. Nowadays new shit means even shittier shit and/or even moar botnet that datamines you as much as it can. Where did it all go wrong? Was it even avoidable?
It's not just DX12. Even on the non-Windows side of things it seems like Vulkan is also fucking dead.
I sincerely wonder why. Vulkan and DX12 are both supported on numerous generations of Nvidia and AMD shit now. I'm not a game developer though so I have little room to speak
Valve and AMD are working on it. Valve intends to push a Linux based console soon and invest more into open standards.
Because they're new and much more difficult to implement. Rewriting engines to support even one of those two would take a long time and a lot of money. All game dev companies want to save as much money as possible, which means staying on older technology like dx9/dx11/oGL and improving the current games on those. This is why dx9 is still used on some games. It's just not worth pushing out a dx12 title. Vulkan, however, is better since it's supported on Mac/Linux/Android and consoles so porting games will be possible.
Are you a time traveler? Didn't they say this several years ago prior to the launch of the Steam Box? I think your brain is stuck in 2010 m8
Are you high? I'm not talking about the OS, I'm talking about a console made by Valve, or possibly Atari if they partner up. Valve only gave out SteamOS to hardware manufacturers which branded the PCs with it as Steam Machines and they were a failure, but valve never made their own console and never claimed they will. It's pretty much confirmed they're working on it now and they made a post explaining that they're still working on Vulkan. So vulkan is far from dead.
systemd, wayland, gnome3, half of the linux kernel codebase.
They've already released one called the Steam Link, it's a low powered Linux based ARM console designed primarily to link a gaming PC and a television in another room over a network with low latency for gaming. It can be considered a console similar to the Ouya or Nvidia Shield since it can be used as a standalone device that has a native app SDK with games released for it and its own controller.
I've seen threads for it on /v/ recently where even on sale for $1(plus $15 S&H) it's not considered worth it.
The only changes today are hardware getting faster slower and software getting slower faster. Everything gets more bloated and does less at the same time. Bloat is the opposite of features. Features eliminate bloat. Standard hash tables or trees eliminate the bloat from every program needing a map data structure. On UNIX, every interpreter has its own kind of map for environments and associative arrays, but they're not compatible and can't be shared, and most of them are inefficient. It's better to have built-in implementations that work and are debugged and fast. This doesn't stop anyone from making their own version, but there would be no point unless it's better, and then you can add your better version to the OS, to improve every program.
C and UNIX. Combining different languages used to be a goal of operating systems like Multics and VMS, which have data descriptors so you can pass data between programs without losing the types, but UNIX doesn't work that way. You have to convert everything into the limited types used by C with an FFI. C is a "foreign" language that sucks, but it must be used because you have no other choice. You can't share data types like hash tables, bignums, and strings. You should be able to use libraries written in different languages without writing the whole project in that language or pretending you're using C. There's the JVM and .net, but those are not on the OS level like the descriptors and the Lisp machines were.
en.wikipedia.org
It's avoidable with a good operating system and new hardware.
Once one strips away the cryptology, the issue is control.UNIX is an operating system that offers the promise ofultimate user control (ie: no OS engineer's going to take away from ME!), which was a good thing in itsinfancy, less good now, where the idiom has caused hugeredundancies between software packages. How many B*Treepackages do we NEED? I think that I learned factoring inhigh school; and that certain file idioms are agreed to inthe industry as Good Ideas. So why not support certaincommon denominators in the OS?Just because you CAN do something in user programs does notmean it's a terribly good idea to enforce it as policy. Ifsociety ran the same way UNIX does, everyone who owned a carwould be forced to refine their own gasoline from barrels ofcrude...
Yes, and they've succeeded. Hordes of grumpy C hackers are complaining about C++ because it's too close to the right thing. Sometimes the world can be a frightening place. I've been wondering about this. I fantasize sometimesabout building better programming environments. It seemspretty clear that to be commercially viable at this pointyou'd have to start with C or C++. A painful idea, but.What really worries me is the impression that C hackersmight actively avoid anything that would raise theirproductivity. I don't quite understand this. My best guess is thatit's sort of another manifestation of the ``simpleimplementation over all other considerations'' philosophy.Namely, u-weenies have a fixed idea about how much theyshould have to know in order to program: the amount theyknow about C and unix. Any additional power would come atthe cost of having to learn something new. And they aren'twilling to make that investment in order to get greaterproductivity later. This certainly seems to be a lot of the resistance tolisp machines. ``But it's got *all* *those* *manuals*!''Yeah, but once you know that stuff you can program ten timesas fast. (Literally, I should think. I wish people woulddo studies to quantify these things.) If you think of aprogramming system as a long-term investment, it's worthspending 30% of your time for a couple years learning newstuff if it's going to give you an n-fold speed up later.
no instead we should have the government provide the gasoline and if you want to use a different type your going to need approval and a license.
who wrote this?
Remember how Valve has begun making actual games again because they pissed off too many people and Jewben has been pissed off at how employees do nothing all the time?
They'll put out some shit game instead of a proper HL3 and release it with the console in a bundle.
I do believe that that vulkan is getting adopted into a lot of popular game engines now.
You better hope to yourself that you're bullshitting because having a graphics API take up half a kernels codebase sounds awful
i'm primarily bitching about the half a million options in kernel configuration that are described with nothing more than a sentence or two if your lucky.
this one actually has elaborate documentation if you do some digging, which is the opposite problem
man7.org
qmonnet.github.io
i could spend a month figuring out how to use that, for a single kernel option. i mean does this really need to be inside of the kernel? can this not be done in userland? tcpdump is the only relevent program that seems to use it. it's like someone rolled their college thesis into the linux kernel, because fuck it, why not.
Not a console if it doesn't run games. It's a relay.
in the LISP world, you would tickle your todger until you splooge, then write the word 'gasoline' in your cream, feel guilty, fall asleep, and forget to buy your groceries
No, fuck you and your meme machines.
Why ? what do you think is the ideal ratio ? 80% usb ? 20% scheduling ?
Lisp machines don't have a kernel, so it's more like everything is on your property and you don't have to ask anyone. You can change any code, including the microcode.
I know that's a hard concept for you weenies to wrap your head around. Your Intel CPU has a crappy version of UNIX that you can't get rid of, your EFI is written in C and sucks, and your kernel is bloated and sucks. In your world, it's hard to imagine a computer that doesn't suck, with an OS that's smaller than any one of those bloated C programs individually, but more powerful and more useful than all of them put together.
Your message to unix-haters of Tue, 24 Sep 1991 14:15:45 PDT was forwarded to all members of the computer research staff at MPCSL. I thought I would send you some comments. I have been a UNIX-hater for 15 years, which is how long I have been at MPCSL. I avoided the UNIX revolution until it was recently foisted on me. At MPCSL, we formerly had three completely incompatible programming environments: InterLISP, Smalltalk, and Cedar. This was viewed by the new powers as very bad and in need of fixing. So we moved to commercial UNIX-based platforms. So now we have about 30 incompatible systems (text editors and formatters, mail systems, versions of the OS, file formats, programming languages, window systems, window managers, toolkits, ... ). instead of three, with more being added every day. Top this with the incredible morass that is SunOS and it is no wonder that you are wondering. Up until recently, we owned everything from the hardware to the microcode to the applications. We could fix anything that broke at any level; we could evolve wonderful new systems. How do we "fix" the X11 releases or the SMTP protocol or SunRPC?? In my opinion, things got the way they are because market forces completely overwhelmed technological forces. Because UNIX was free (or nominally licensed) it came into wide use, first in CS and EE departments and later in the world. To some, moving from MS-DOS or worse, it seemed like a win. To those of us who have been around for a while and are aware of the alternatives, it seemed like a nightmare. We thought it would go away when users came to their senses. We were naive. Sigh. Meanwhile, thanks to BSD, UNIX grew like Topsy, or more like barnacles encrusting a sunken ship. Ultimately, UNIX began to be viewed by decision makers who were not technically competent as a panacea for competing technologies.
Windows Vista
Windows 7
Windows 8
Windows 10
>buying computers with (((U)))EFI
lol
Why are you saying this in the present tense like lisp machines still exist?
Unixhater fag isn't going to do any of this himself, he's going to bitch until he either creates more clones of himself or annoys someone into implementing a LispOS for him.
ye. except I feel the first good OS will be when we use one language and pass around its types, instead of having a language agnostic data type. at least the lisp niggers knew some shit
I'm getting a feeling that dx12 will be shilled hard to push vulkan into obscurity.
Go on, fix the injustice by creating a LISP language with equal to C peformance. Until then it's just shit-posting.
As long as DX12 doesn't gain a massive performance increase over Vulkan all of a sudden it's fucked comparatively speaking.
Why use some proprietary walled garden Wangblows 10 API for your application when you can use the FOSS one with the same performance and features in addition to cross-platform support?
XBOne ports, though I doubt even the X will be enough to bring that back from the grave.
Completely impossible. Everyone except Microsoft is working on Vulkan.
it looks like they know this which is why they're just trying lal this bullshit torvalds is dealing with now
Both DX12 and Vulkan are low-level APIs that defer control to the application developer. Both are reliant on vendor extensions to offer new functionality, unlike previously when it was entirely up to the API itself to offer new features. One runs on one platform on one OS, the other runs on hundreds of devices and any OS. It's a losing battle any way you look at it.
It's obviously for DRM, he probably knows.
Vulkan 1.1 added DRM support btw.
Not him, but properly compiled Lisp is very performance. I mean, they used Lisp on 60's mainframes and even minicomputers.
The basic car and cdr operation translated to 4 IBM 704 instructions each. With tail call recursion, you go much easier on the stack.
Except the license and approval things are exactly how Unix goes.
Meant for
kys 12 year old
Ah, if things were that simple we would almost not have proprietary software left
MS has other ways of pushing their stuff, and the game industry is still trapped under their claws
The Xbone is floundering though. It's not like it was last gen with the 360.
Three things are needed for a performant language:
I'm not aware of any LISP or similar that passes all three, especially GC.
This shows how utterly ignorant the average macfag is.
For starters, Lisp compiles directly to assembly. Then, inline assembly is absolutely not a requirement. Fortran and C are universally considered fast, yet none of them includes inline assembly (C's inlined assembly is a GNU extension).
As for the GC, do you really think Lisp machines had a garbage collection thread?
Why don't you keep on sucking cock elsewhere?
Is there actually a LISP that can create executables without megabytes of runtime boilerplate glued to it?
Did you just move the goalposts?
interpreters can be performant retard. just because jabbascript is complete aids doesn't mean they're all bad. gfo
Worse, Lisp isn't even a language that needs to be interpreted, in fact it started out as a compiled, bare-metal language.
>Compiles directly to assembly, no emulator, interpretor, or runtime.
Nope
I'm not saying script interpreters are bad, just that they aren't suited for systems development like real programming languages.
You realize whether a Lisp is compiled or interpreted is dependant on the implementation, right nigger?
Originally, Lisp was literally executed directly in the CPU (see Lisp Machines).
...
...
...
>>>/g/
Lisp compiles without a runtime. There were computer before 2003, which must be when you were born, retard. Among these computers were the Lisp machines, running bare metal Lisp.
That's because it compiles with a compiler baka.
HAHAHAHAHA!!! WOW by that definition, I guess Java must "compile without a runtime" too, since all those crappy Java processors were built in the '90s to ameliorate the torrent of streetshitters that flooded the mobile/embedded market!
Can't wait for hardware built around pic related!!
Can you please select, right click, copy, go to quick reply window, right click, paste, the paragraph where I talked about that? Thanks in advance.
Oh, wait, you think Lisp needs a GC, don't you? No, surely you can't mean that. No one would be so uneducated as to believe it AND post about it on an imageboard.
en.wikipedia.org
Also, your refrain of CPUs being "designed for C" is amusing, considering that at least one actual "C machine" exists, the AT&T Hobbit.
Yeah, Wikipedia. That's what you know about Lisp. You schemed (lol XDDDDDD) over the article and think you're a Lisp expert
First Startpage results for "Lisp without GC"
github.com
github.com
How many years of experience do you have in programming, again?
it will die when pajeet tier tech nerds stop telling their friends to upgrade to 10
All of the "GC-less Lisps" I'm aware of, while quite fascinating in a Rust-like way, are pretty obscure and undeveloped, probably because it's necessary to break so many basic assumptions of (and so much compatibility with) the language that it's questionable whether or not they can really be called Lisps.
There's also still the issue of the megs of suspicious looking interpreterslibraries glued to "compiled" binaries.
The sources of these implementations are free for anyone to modify, use and redistribute. This means you are free to examine them.
I've been looking into the Steam Link a bit more and found this
This thing is even worse than I thought.
I don't consider mobile card game shit to be 'actual games' compared to what they used to make.
A simple relay wouldn't have OpenGL ES 2 and SDL 2 support in its SDK. "Littlefoot" was intended to become a cheap low powered console similar to the Ouya and Android based consoles at the time to create a catalog of simple games alongside PC game streaming that they'd offer on their Steam App which would later be installed on most smart televisions and combine with their convoluted mobile strategy.
This interview from 2013 gives a good rundown of what was going on
>The thing we’re working on with [Nvidia] is that you’ll be in your living room and your TV will potentially be connected either through wireless or ethernet. You’ll pick up a controller and Big Picture will come on. It’ll be integrated into all the TVs after a certain point, it’s like HDMI+. The problem to solve is how to interact with a web browser, how to get all the games to support controllers, and how to make it all seamless.
theverge.com
The Steam Link, Steam Controller and Steam Machines are all perfect examples of shit no one needed or wanted. Just because they didn't release any games for it and gave up on it almost immediately doesn't mean that it isn't a Linux based video game console.
LISP machines had hardware garbage collection.
Also,
github.com
github.com
It's absolutely amazing that, during the extensive nadir of the console market at the tail end of the zombie 7th-gen into the extremely slow and unenthusiastic launch reception of 8th-gen, all Valve would've needed to do is make the Steam Machine OEMs sell decent price-competitive prebuilts targeting the console market directly. All those $200-$500 "console killer" builds stickied on /r/PCMR could've been sitting in normalfag brick & mortar outlets, running games better than the consoles beside them on the shelf, with identical prices. Consoles would've died and stayed dead in 7th-gen.
But instead, Steam Machines were "muh premium console" $1k-$3k memes, apparently because Valve's idea of a low end option was the "smart TV"/cellphone shit you talked about, and now gaming PC prices are shot all to hell compared to consoles thanks to DRAM pricefixing and cryptoponzi miners.
Hardware GC is still GC, with all that entails. I mean, there were "Java machines" too, and they still suffered the problems inherent to such languages.
And those languages you linked, while interesting in their own right, much like Rust, are of questionable compatibility with and relationship to Lisp.
bump