Menu
▾
▴
#118 C and Perl are not sexy.
open
nobody
None
2019-09-17
2019-09-17
Anonymous
No
Originally created by: fuzzynoise
I have issue with too few issues.
I believe from the core of my being that backup is important. I KNOW that tape backup is cheap while effective and I know that Amanda offers a flexibility that is ABSOLUTELY invaluable. I want Amanda to progress into the 21st century tho, and a lot of that requires EG translations to Python over Perl and...smart bois looking at C so we can write either better C or ASM. Obviously, I don't think machine problems are solved by floating away from the machine. We need some bare-metal. I know there is a commercial UI....but what if it was a user UI? I only ask since I forget what the U in UI stands for...
What do people think? What would you want? What is your use case?
EDIT: user story
Originally posted by: chassell
MOARR BUZZWORDS! WRITE IT ALL IN NODE.JS AND THEN OPTIMIZE IT IN THE CLOUD!! PAY AMAZON EVERY SINGLE DOLLAR YOU ... oh wait not supposed to write that down... oops..
Originally posted by: fuzzynoise
That's a lovely idea. I don't think that the next best thing is the best
thing...but I think the old thing is old.
On Tue, Sep 17, 2019 at 4:39 PM chassell notifications@github.com wrote:
Originally posted by: chassell
For my part .... the issues of changing language base come down to this:
1) Avoid tech-debt tangles that keep bugs/misfeatures from being ever fixed or extended. (REAL!!)
[people already consider that a sign-o-death for other projects]
2) Avoid legacy problems with many modules being unchangeable due to interconnection to others
[no evidence anywhere of this? none?]
3) Allow dynamic UI events and failure detection but retain SELinux/Linux/OS-Insensitive CLI API
4) Yes, allowing Python / Go and (cringe) JScript event APIs in someday may be a futureproof key
Genuinely and truly... there's a reason many other languages (and NPM!!) are not wise in the infrastructure-and-OS-domain. No matter how many docker versions or VMs one creates ... you are only intending to securely snarf up and then retrieve [maybe] one little part of a backup. That's big raw data and simple, crucial, no-dicey-systems permissions allowed.
[NOTE: if you have translated a VM's multi-gig disk storage into JSON data ... you may have used the wrong tool for the problem. ]
Modern architectures are, well, good for making data-sniffing UI sites.... because money. M$ already tried to make C# (and others tried Java) as their systems language and it failed HARD. It's hardcore languages or nothing for the ins and outs of raw bytes.
Originally posted by: chassell
TL;DR: C and PERL ... are not sexy. Neither is fishing a palette out of a warehouse. :-].
Originally posted by: fuzzynoise
Obviously, we're still looking relatively low RE data moving since...data is a low level abstraction. You want to move ones and zeros? Let's move 'em. I don't know if this can be done better. JLM and the whole previous team did a great job with their idea of hardware and the greatest IO system (the internet) at the time.
Yes, this is wildly correct. There are bugs up and down. How do we write it so folks between 15 and 40 understand where the bugs are?
Absolutely. This can be automated to a large extent with consent (I am an SELinux expert). I'd love to see more packaging folks get interested.
Yes. There should be easily built-in plugins. I don't know what language should be, hence the issue...but it should be something current currently. I don't think you can future-proof without idiot proofing and those folks are ingenious.
EDIT: Thanks for the reply @chassell it's definitely important to consider if there is any hope for long(er) term continuation, and I'm glad it's open for discussion.