Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 47 48 49 50 [51] 52 53 54 55 ... Last
[#] Mon Dec 24 2018 15:21:35 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Cool: "Therebve been some improvements to interop - you can now host windows applications inside tmux and screen without them destroying the rest of the window!"

[#] Wed Dec 26 2018 22:09:36 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Nonetheless, docker (not necessarily k8s; you don't need k8s to do
docker) is the new standard and in most respects, our consultants
dragged us kicking and screaming into the new reality. And they were
right.

Right ... I've deployed Docker containers on "regular Linux" a few times.

But if you're building a dedicated environment to run Docker stuff, k8s seems to be the most popular way to do it?

[#] Thu Dec 27 2018 20:14:44 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Dunno why someone would do that when they could just run Qt everywhere. (It even works with Python now!)

[#] Wed Jan 02 2019 14:48:40 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Well...

1. Qt requires learning Qt, at the very least. Which only really works with Qt. Whereas an Electron app can be easily turned into a web page.
2. Qt requires the Qt libs, which may mean dealing with FOSS stuff. Electron does, too, but isn't as fussy as Qt about it.

For my needs, at least, Qt is not an option.

Concern #1 there, though, kind of makes me sad in some ways. We're turning JavaScript into the language of choice for GUI development. Is this really a good idea?

[#] Sat Jan 12 2019 20:37:32 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

JavaScript is becoming the language of choice for pretty much everything, actually. Except for the Gotards who think they're going to replace C with Go. We call those people "future C programmers"

[#] Sat Jan 12 2019 22:32:48 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Maybe, I dunno... JavaScript is just... er... strange in certain ways.

[#] Fri Jan 25 2019 22:55:06 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


k8s may well be the most popular, but it is more complex than its competition and it's not as well-integrated into the amazon environment in particular. (that's starting to change with EKS but it's still less of an AWS-native solution, in my view, as it wants to do things its own way.)


long and short, docker is the standard but for the underlying docker-compliant deployment cluster there are at least 3 competing alternatives. ECS is my choice in an Amazon environment.

[#] Mon Jan 28 2019 14:50:54 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

JavaScript was a hack, just like PHP was. It just happens to have evolved into a real language somewhat more elegantly than PHP did.

[#] Wed Jan 30 2019 17:18:31 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


There's that.

You can't retcon a language. You have to build with whatever came before.

And nobody can anticipate where programmers will want to go with a language.
At least, not perfectly. So, yeah, sometimes the language goes absolutely south, but sometimes it just kinda gets weird, but manages to hang on.

C++... heh... to consider a language that's grown weird thanks to evolution.

[#] Wed Jan 30 2019 17:22:57 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


k8s... that's that... what... kuberknocknees thing or whatever?

I've been curious about that. We could benefit from something that lets us build out a full virtual environment in one place, then deploy it to this cloud engine, or that one (AWS, or Google Cloud, or some local customer site without internet access, or whatever). I'm lead to believe k8s could do that, but I haven't had time to research it well enough.

[#] Thu Jan 31 2019 19:30:26 UTC from Ragnar Danneskjold

[Reply] [ReplyQuoted] [Headers] [Print]

We do that with Openshift and Kubernetes.

[#] Fri Feb 01 2019 00:12:34 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


So yeah, my new shop runs node.js. I'm not a huge fan. Seems like a toy environment. But that's what we said about Java back in 2000-2004.

TypeScript makes it less horrible, but the underpinnings are weak. Absolutely no preemptive scheduling, so you have to resort to hacks if you're doing anything cpu-intenssive. Cluster mode is really suboptimal - 1 heap per cpu core. and so on.

People complain a lot about threaded languages, but I never had a huge problem with Java. You do have to keep a close eye on your junior programmers to make sure they don't mutate the class variables of service classes, but it's not usually a big problem.

A lot of the thread-hostile languages take their hostility just a little too far. It would be nice to have a language where state is shared-nothing *by default* but can easily be shared...

[#] Fri Feb 01 2019 00:15:27 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

You can't retcon a language. You have to build with whatever came
before.

yeah, PHP tried retconning (php5) and look where it got them. python3 broke everything too, but at least they were a lot more explicit about separating the versions and the migration path.

[#] Fri Feb 01 2019 00:21:32 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


you can get about 90% of the way to this cloud-independence nirvana with just docker-compose... ECS command-line tools accept docker-composse files as input...

[#] Fri Feb 01 2019 16:58:03 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

retcon? was is das?

[#] Fri Feb 01 2019 20:49:52 UTC from Haven

[Reply] [ReplyQuoted] [Headers] [Print]

Retcon = Retroactive Continuity.   Often used in fiction, in how someone might rewrite a past event in the story.   

From the web:

noun
 
  1. 1.
    (in a film, television series, or other fictional work) a piece of new information that imposes a different interpretation on previously described events, typically used to facilitate a dramatic plot shift or account for an inconsistency.
    "we're given a retcon for Wilf's absence from Donna's wedding in ‘The Runaway Bride’: he had Spanish Flu"
verb
 
  1. 1.
    revise (an aspect of a fictional work) retrospectively, typically by introducing a piece of new information that imposes a different interpretation on previously described events.
    "I think fans get more upset when characters act blatantly out of established type, or when things get retconned"


[#] Sat Feb 02 2019 16:17:18 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I was able to learn as much from a quick DDG search. I'm trying to understand how the word applies to programming languages.

[#] Tue Feb 05 2019 17:07:37 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


I took his usage of that word to mean, "changing the semantics of a language in a highly backwards-incompatible way, because of better-design-remorse on the part of the language designer"

[#] Mon Feb 18 2019 15:33:11 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Yeah, LS got it.

In my mind, when you retcon a comic book, you're changing the character's backstory to fit some other direction that you want to take the character.

But you can't do the same thing with a computer language... you can't just change the language to make it go in new direction (at least, if it is a well-used language), because all the old code relying on the broken semantics of the old language constructs requires it continue to work that way. You'd impose a ridiculous amount of work on so many people, they'd most likely abandon the language rather than embrace the change.

Which is kind of funny, as people might abandon the language eventually anyway if it continues to make their job harder.

[#] Mon Feb 18 2019 15:39:13 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I wish I could research that right away.

We continue to embrace a particular vendor that I kind of despise (because of the way they have treated us in the past). I would prefer us to prepare our product in a way that would allow us to jump to a better vendor should one arise (or to our own version of what the vendor does, should we ever decide to put up the money to do it). The more stuff we build in that vendor's environment, the worse the situation gets, to my view.

Besides, there is value in keeping the vendor on their toes. A vendor who needs us, but thinks we need them, doesn't react as well to problems as one that needs us, but doesn't think we need them.

Go to page: First ... 47 48 49 50 [51] 52 53 54 55 ... Last