I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad
-
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
The real question is how to make it possible to write adequate software on schedule and under budget.
Machine learning ... just write a short prompt about the program and the AI networks will do the magic for you.
Filed under: KNUT-H
Well, they might get me sued because apparently copyrighted code from not so public repos has been included⌠and thatâs before we get into licence issuesâŚ
-
@Arantor Eh. Solvable. Only ever hand out obfuscated binaries. All the cool kids do it.
-
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
Well, they might get me sued because apparently copyrighted code from not so public repos has been includedâŚ
I hope nothing from our private repos gets out like that. It's awful stuff, a grafting together of Perl and Verilog.
-
@error said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
Do you want Skynet? Because that's how you get Skynet.
You only have to be careful to not ever have another network that generates prompts for that network. Should be fineeeeeeeee.
-
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
The real question is how to make it possible to write adequate software on schedule and under budget.
Machine learning ... just write a short prompt about the program and the AI networks will do the magic for you.
Filed under: KNUT-H
Well, they might get me sued because apparently copyrighted code from not so public repos has been included⌠and thatâs before we get into licence issuesâŚ
Eh, Microsoft has done basically the same with their github copilot, violating the copyright of every open source project ever. And do they care?
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
The real question is how to make it possible to write adequate software on schedule and under budget.
Machine learning ... just write a short prompt about the program and the AI networks will do the magic for you.
Filed under: KNUT-H
Well, they might get me sued because apparently copyrighted code from not so public repos has been included⌠and thatâs before we get into licence issuesâŚ
Eh, Microsoft has done basically the same with their github copilot, violating the copyright of every open source project ever. And do they care?
Some OSS projects (with more permissive licenses) won't care at all. And I bet there's someone at Github worried about the other cases, on the grounds that they should have filtered things by what Legal thought was allowed prior to building the training dataset and yet an idiot forgot to do that...
-
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@boomzilla he reminds me of my stepdad and his âdevelopers should write everything in assembly, itâs so much fasterâ while ignoring all the realities of that.
Ideal reply: "
It's possibly a bit faster to run, but it sure isn't faster to write, by many orders of magnitudeWelcome time pod traveler."
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@boomzilla he reminds me of my stepdad and his âdevelopers should write everything in assembly, itâs so much fasterâ while ignoring all the realities of that.
Ideal reply: "It's possibly a bit faster to run, but it sure isn't faster to write, by many orders of magnitude."
The real question is how to make it faster to write good, correct software. Neither the assembly of old nor the new-fangled JS excrements are any good at that. Although, back in the day things might have had fewer bugs by virtue of being generally smaller and updates being more costly.
May I refer you to Frederick Brooks's article called "No Silver Bullet"?
-
@Mason_Wheeler said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@TimeBandit said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
You think Python and NodeJS are installed by default?
Python definitely is on many Linux distros, but I haven't heard about Node being installed by default. You'd really hope the people in *nixland aren't that dumb... but then you remember they're voluntarily living in *nixland.
Weyland and systemd makes me think that there must be node somewhere in Ubuntu.
-
@Steve_The_Cynic said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@boomzilla he reminds me of my stepdad and his âdevelopers should write everything in assembly, itâs so much fasterâ while ignoring all the realities of that.
Ideal reply: "It's possibly a bit faster to run, but it sure isn't faster to write, by many orders of magnitude."
The real question is how to make it faster to write good, correct software. Neither the assembly of old nor the new-fangled JS excrements are any good at that. Although, back in the day things might have had fewer bugs by virtue of being generally smaller and updates being more costly.
May I refer you to Frederick Brooks's article called "No Silver Bullet"?
Sure. Doesnât mean you have to use a turd blaster, though.
-
@TimeBandit said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Mason_Wheeler said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
they're voluntarily living in *nixland.
At least, our files are where we left them
Well, unless you install a kernel update that renames your disk devices. BTDT. Fortunately, I was able to recreate the partition scheme exactly on the "new" disk device, and â what do you know â all the files were indeed right where I'd left them. It could have been a disaster, though.
-
@Zecc said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gribnit said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
I work in PHP and JavaScript because someone has to...
It's not true! Nobody has to do this! Cast off your mind-forged chains! Or whatever just stop.
Not even a follower of The Old Ones wants PHP and JavaScript.
Um, so, me and a buddy one time, we, we bikeshedded a tabletop RPG runner that would accept PHP from the JS client for custom rules.
And as far as I know we are both followers of the Old Ones.
-
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
Someone has to prop up the ecosystem because I'm not clever enough to work in a real language.
Nah, we really could just let it collapse, it's fine.
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Steve_The_Cynic said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Arantor said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@boomzilla he reminds me of my stepdad and his âdevelopers should write everything in assembly, itâs so much fasterâ while ignoring all the realities of that.
d4
Ideal reply: "It's possibly a bit faster to run, but it sure isn't faster to write, by many orders of magnitude."The real question is how to make it faster to write good, correct software. Neither the assembly of old nor the new-fangled JS excrements are any good at that. Although, back in the day things might have had fewer bugs by virtue of being generally smaller and updates being more costly.
May I refer you to Frederick Brooks's article called "No Silver Bullet"?
Sure. Doesnât mean you have to use a turd blaster, though.
If the job requires a turd blaster, either you do it with a turd blaster or you don't do it at all.
-
@dkf said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
grafting together of Perl and Verilog.
Ah, two of my favorite languages!
-
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
Should be fineeeeeeeee.
Is the eeeeee the screech you make as everything goes horribly wrong?
-
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But every system comes with an assembler!
Technically not true. There are platforms where arbitrary code execution is entirely prohibited for unprivileged users. Android tried to be like that by forcing everyone to use Java, before the reality of 2007 mobile hardware performance hit them. I believe it's totally doable with today's technology. We're already most of the way there with everything bding written in JavaScript. Also, unironically WebAssembly.
-
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But every system comes with an assembler!
Technically not true. There are platforms where arbitrary code execution is entirely prohibited for unprivileged users. Android tried to be like that by forcing everyone to use Java, before the reality of 2007 mobile hardware performance hit them. I believe it's totally doable with today's technology.
Sure, but then again, FORTRAN-IV isn't all that popular on Android either.
-
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But every system comes with an assembler!
Technically not true. There are platforms where arbitrary code execution is entirely prohibited for unprivileged users. Android tried to be like that by forcing everyone to use Java, before the reality of 2007 mobile hardware performance hit them. I believe it's totally doable with today's technology.
Sure, but then again, FORTRAN-IV isn't all that popular on Android either.
Is FORTRAN-IV popular anywhere these days? (No, I don't mean Fortran-77, but specifically FORTRAN-IV.)
-
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
There are platforms where arbitrary code execution is entirely prohibited for unprivileged users
The question is what you mean by "arbitrary code execution". Being able to execute JVM code could as well count as arbitrary code execution. On the other hand, being able execute x86 machine code might not - there are instructions that unprivileged users can't execute.
It depends entirely on what you want to prevent/limit. Besides, you can write JVM bytecode in an assembler-like fashion. Wouldn't recommend it, but it's just yet another ISA.
-
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
write JVM bytecode in an assembler-like fashion.
-
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
There are platforms where arbitrary code execution is entirely prohibited for unprivileged users
The question is what you mean by "arbitrary code execution". Being able to execute JVM code could as well count as arbitrary code execution. On the other hand, being able execute x86 machine code might not - there are instructions that unprivileged users can't execute.
I meant managed v. unmanaged. That alone makes a world of difference.
It depends entirely on what you want to prevent/limit.
I want to prevent @LaoC from being right, 's all.
-
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
I want to prevent @LaoC from being right, 's all.
-
@Gustav A concrete example comes from a service that has to run "outside" user code. It's virtualized/containerized and locked down to a decent degree. There's little permanent damage that an user can do outside of their little sandbox. But that hasn't prevented e.g., certain users from trying to run something like a cryptominer in that sandbox. (I doubt it was particularly useful - there's not a lot of CPU power there, and they should have timed out after relatively short run times.)
But, still, even managed vs unmanaged code wouldn't make much of a difference here.
-
@cvi well, for one, it's much harder if not impossible to exploit Meltdown and friends in managed environment.
-
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi well, for one, it's much harder if not impossible to exploit Meltdown and friends in managed environment.
Rowhammer remains available via abuse of array copy, but good fucking luck aiming it.
Branch predictors do verge on dangerously clever, so I would not assume SpecEx weirdness to be totally dead without actually memory protection vs broken.
-
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But every system comes with an assembler!
Technically not true. There are platforms where arbitrary code execution is entirely prohibited for unprivileged users. Android tried to be like that by forcing everyone to use Java, before the reality of 2007 mobile hardware performance hit them. I believe it's totally doable with today's technology.
Sure, but then again, FORTRAN-IV isn't all that popular on Android either.
Soon.
-
@HardwareGeek said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
write JVM bytecode in an assembler-like fashion.
Says the guy who uses Perl to write Verilog, or something like that.
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@HardwareGeek said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
write JVM bytecode in an assembler-like fashion.
Says the guy who uses Perl to write Verilog, or something like that.
I don't remember anything specific, but I've probably done that. I know I've used Python to generate SystemVerilog.
-
@HardwareGeek said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@cvi said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
write JVM bytecode in an assembler-like fashion.
Yeah it's called BCEL and if you have to use it you either fucked up (9) or are a gott-damnted genius (1).
ed. real odds worse
-
@Gribnit that's some weird man page sections you got there.
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gribnit that's some weird man page sections you got there.
I'm running System ââ
-
@topspin said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But I couldn't use it because in this project we use Node 9, and Node didn't have Array.prototype.map until version 11.
Wouldn't that be like a three line polyfill to add?
And even without the polyfill, for(i=0...) loops work just fine, as much as we're all allergic to them these days.
-
@Steve_The_Cynic said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
@LaoC said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
But every system comes with an assembler!
Technically not true. There are platforms where arbitrary code execution is entirely prohibited for unprivileged users. Android tried to be like that by forcing everyone to use Java, before the reality of 2007 mobile hardware performance hit them. I believe it's totally doable with today's technology.
Sure, but then again, FORTRAN-IV isn't all that popular on Android either.
Is FORTRAN-IV popular anywhere these days? (No, I don't mean Fortran-77, but specifically FORTRAN-IV.)
It's -90 if anything, IV is probably on par with II.
-
@Gustav said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
It depends entirely on what you want to prevent/limit.
I want to prevent @LaoC from being right, 's all.
That's fine with me, I was just echoing your "I can't use dependencies from the system repo" argument to support the case for assembler. It wasn't supposed to be rightâ˘.
-
@Carnage said in I knew Python was slow, but not THIS slow. And I knew JS was bad, but not THIS bad:
Weyland and systemd makes me think that there must be node somewhere in Ubuntu.
Those two components are not the ones that should make you think that. Not the least because they are the two components that were created pretty much in spite of Ubuntu, which had its own versions, mir and upstart respectively.
I think there isn't actually node. There is javascript in the Ubuntu Desktop, the gnome shell is in large part written in it, but it is a web view using webkit libraries.