Linux: vim isn't moe

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Linux: vim isn't moe

«‹›1097 »

pram: Jun 10, 2001

Cocoa Crispies posted:

yeah that's a problem with the application, not my butt

some prole autoscales low hanging fruit poo poo like a php website and suddenly thinks you can do it to everything

# ? Aug 19, 2014 01:11

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 11:02

pram: Jun 10, 2001

just rearchitect your application to use cassandra :smug:

# ? Aug 19, 2014 01:12

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

actually the reason most things cant scale to a large level is because they're poorly designed by people who wanted to do it themselves

most of this stuff is a solved problem as long as you dont try to solve it yourself

# ? Aug 19, 2014 01:13

pram: Jun 10, 2001

uhh no the reason enterprise applications cant scale like NETFLIX is because they were made years ago and the newest thing they designed for is 'cluster computing' see: oracle fusion

# ? Aug 19, 2014 01:16

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

you mean the company that uses microsoft silverlight?>?

# ? Aug 19, 2014 01:20

pram: Jun 10, 2001

or really any relational database, scales like poo poo. how do you design your mysql app to span geographic regions and be active/active ?? if your application wasnt designed to be in the cloud from the start its going to be a pos

# ? Aug 19, 2014 01:21

Notorious b.s.d.: Jan 25, 2003; by Reene

to a first approximation no applications are meant to autoscale horizontally or failover across active active datacenters, because that poo poo is hard, expensive, performance-impacting, and usually totally loving impractical

netflix can be magical autoscaling wonder wizards because it doesn't matter if 10% of their requests fail or the system isn't globally consistent or performance is degraded or whatever. the loving client can just fail over and your movie is delivered 30 seconds late or stutters or you don't have hd that night. big whoop

the rest of us, poo poo has to be up and deliver on certain performance/uptime guarantees during particular hours, and extraordinarily rare events like a datacenter failure are less important to cope with than extraordinarily common events like an amazon datacenter failure

p.s. you still want cfg management and one-button deployments even if you're just deploying to the same dozen FIPS-certified ultraSPARC NETRAs from 2005 though. those things are important man

Notorious b.s.d. fucked around with this message at 02:45 on Aug 19, 2014

# ? Aug 19, 2014 02:42

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

wrap it up linuxailures

http://arstechnica.com/business/2014/08/linux-on-the-desktop-pioneer-munich-now-considering-a-switch-back-to-windows/

# ? Aug 19, 2014 13:39

jre: Sep 2, 2011; To the cloud ?

Captain Foo posted:

wrap it up linuxailures

http://arstechnica.com/business/2014/08/linux-on-the-desktop-pioneer-munich-now-considering-a-switch-back-to-windows/

quote:

Agreed. Is there any way you can look at this and not think 'shady' especially with all of MS's previous dirty dealings.

quote:

I smell sabotage, likely indirectly. Microsoft has a lot riding on the failure of this project, if more municipalities follow this example it stands to lose millions.

quote:

Just remember that this probably all because some poor public servant's Powerpoints get screwed up in LibreOffice, nothing more.

quote:

I have no clue why this is controversial. First, the guy in charge is a proclaimed Microsoft fan. Second, Microsoft is no angel and doing dirty deeds was something they were well known for throughout the 80s and 90s. Third, do you know how easy it is for the guy on top to sabotage a project? Any project? Killing an OS migration would be like shooting fish in a barrel, point blank, with a rocket launcher.

jre fucked around with this message at 14:17 on Aug 19, 2014

# ? Aug 19, 2014 13:53

MononcQc: May 29, 2007

Notorious b.s.d. posted:

to a first approximation no applications are meant to autoscale horizontally or failover across active active datacenters, because that poo poo is hard, expensive, performance-impacting, and usually totally loving impractical

netflix can be magical autoscaling wonder wizards because it doesn't matter if 10% of their requests fail or the system isn't globally consistent or performance is degraded or whatever. the loving client can just fail over and your movie is delivered 30 seconds late or stutters or you don't have hd that night. big whoop

the rest of us, poo poo has to be up and deliver on certain performance/uptime guarantees during particular hours, and extraordinarily rare events like a datacenter failure are less important to cope with than extraordinarily common events like an amazon datacenter failure.

Yes and no. I mean it's fairly obvious that cross-DC failover is hard as gently caress -- the link between DCs to even figure out you need to failover is likely less reliable than individual DCs -- but it totally matters if 10% of their requests fail.

10% of video streaming at their scale is a poo poo ton of load and bandwidth to shift around for the sake of it. It's big enough they need to strike deals with ISPs and carriers to keep delivering poo poo, and doing it while going over adversarial guys like Verizon trying their hardest to ruin their QoS. Sure they don't have a hard need for consistency and clients can retry (which clients can't by the way?), but there's no question that their problems are hard.

It's cool to feel better by telling oneself "well they couldn't scale the systems I work on because they can make compromises", but it's not like their problem space is intrinsically easier to work in than yours or mine, or that their problem space isn't the result of compromises they made already.

IMO the main reasons poo poo can't scale are:

99% of the time it doesn't need to scale as much as you think it needs to
Distributed Systems are hard and still actively researched, and very little open source work exists to be lifted directly into your app. poo poo like the CAP theorem is only starting to be known and people still claim to beat it from time to time.
People are not ready to make the compromises (and deal with the eventual complexity) that makes large-scale systems easier to work with, and do not have the experience to make the non-compromising systems work
It's expensive to develop a large-scale solution. It's expensive to hire and retain experts to help you work things out and design it right. It's even more expensive to bring your solution to maturity.
A large-scale system can't fit into one person's head, and most corporations or teams don't have the logistics in place to ensure the proper communication and collaboration required to keep poo poo working

# ? Aug 19, 2014 15:22

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

jre posted:

Hahaha. They actually believe MS needs to sabotage desktop Linux.

# ? Aug 19, 2014 15:31

jre: Sep 2, 2011; To the cloud ?

Suspicious Dish posted:

Hahaha. They actually believe MS needs to sabotage desktop Linux.

The comments section on that article is predictably terrible slashdot lite.

Your exchange setup can be replaced by gmail,
puppet is a viable replacement for system center ,
ldap is just as good as active directory,
open office isn't a terrible piece of poo poo

:laffo:

# ? Aug 19, 2014 15:42

VAGENDA OF MANOCIDE: Aug 1, 2004; whoa, what just happened here?; College Slice

system center 2012 owns

# ? Aug 19, 2014 16:33

Progressive JPEG: Feb 19, 2003

at my last job i blew a bunch of time getting a basic db to the point where it could handle a few billion records/day on a single system* solely because they didnt want deployments to require several machines (and therefore cost more)

was a p fun project and a hell of a line item on my resume but lmao

* with a small disk array providing p good iop capacity tbf

# ? Aug 19, 2014 16:46

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Mr Dog posted:

A phone that plugs into a docking station to become a desktop is actually pretty ownage

why

# ? Aug 19, 2014 16:52

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Notorious b.s.d. posted:

to a first approximation no applications are meant to autoscale horizontally or failover across active active datacenters, because that poo poo is hard, expensive, performance-impacting, and usually totally loving impractical

netflix can be magical autoscaling wonder wizards because it doesn't matter if 10% of their requests fail or the system isn't globally consistent or performance is degraded or whatever. the loving client can just fail over and your movie is delivered 30 seconds late or stutters or you don't have hd that night. big whoop

the rest of us, poo poo has to be up and deliver on certain performance/uptime guarantees during particular hours, and extraordinarily rare events like a datacenter failure are less important to cope with than extraordinarily common events like an amazon datacenter failure

p.s. you still want cfg management and one-button deployments even if you're just deploying to the same dozen FIPS-certified ultraSPARC NETRAs from 2005 though. those things are important man

crotchety cj stymie

# ? Aug 19, 2014 16:53

pram: Jun 10, 2001

Notorious b.s.d. posted:

p.s. you still want cfg management and one-button deployments even if you're just deploying to the same dozen FIPS-certified ultraSPARC NETRAs from 2005 though. those things are important man

thx person who doesnt know how ansible works

# ? Aug 20, 2014 01:27

pram: Jun 10, 2001

MononcQc posted:

It's cool to feel better by telling oneself "well they couldn't scale the systems I work on because they can make compromises", but it's not like their problem space is intrinsically easier to work in than yours or mine, or that their problem space isn't the result of compromises they made already.

you can scale anything if you have a blank check.

i dont think netflix had it 'easier' but it's certainly 'easier' when your platform architecture is designed that way from the very beginning. instead of shoehorning some crufty piece of poo poo into teh clod

# ? Aug 20, 2014 01:34

pram: Jun 10, 2001

new discussion topic: websphere vs weblogic, the epic final showdown

# ? Aug 20, 2014 01:40

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

pram posted:

it's certainly 'easier' when your platform architecture is designed

#wow #wwhoa

# ? Aug 20, 2014 02:44

raruler: Oct 5, 2003; “Here lies a toppled god —
His fall was not a small one.
We did but build his pedestal,
A narrow and a tall one.”

lurmickes

quote:

On Mon, Aug 04, 2014 at 03:38:20PM +1000, Dave Airlie wrote:
>
> Nick has decided he wants to be a kernel developer, a laudable goal.
>
> He however has decided not to take any advice given to me by a number of other
> kernel developers on how to work on the kernel. So instead he sends random
> broken patches to random subsystems in the hope that one will slip past a sleepy
> maintainer and end up in the kernel.

So far, he has tried to do this with the ext4, btrfs, scsi, and usb
subsystems. I'm probably missing a few. I suspect he's jumping
around to different subsystems hoping to find one where his reputation
hasn't been blackened yet by his refusal to deeply understand kernel
code (or to test to see if it compiles, never mind trying to boot a
kernel with that patch and exercise the modified code) before starting
to try to "help".

Other theories besides the one that Dave has advocated that he's
trying to write a University Thesis on trolling the kernel development
process (either by seeing if an obviously broken patch could be snuck
past the peer review system, or to see if he can try to get someone to
lose their temper much like Linus is supposed to do all the time ---
not realizing that this only happens to people who really should know
better, not to clueless newbies), are that he's a badly written AI
chatbot, or just a clueless high school student with more tenacity
than one usually expects at that age. Or maybe he's trying to win a
bet, or is trying to get extra credit or to complete some course
assignment by getting a patch into the kernel. Or maybe this is just
the universe trying to demonstrate exactly how true the
Dunning-Krueger effect really is....
> He isn't willing to spend his own time learning anything, he is
> expecting that kernel
> developers want to spoon feed someone who sends them broken patches.
>
> We've asked him to stop, he keeps doing it, then when caught out apologizes
> with something along the lines, of I'm trying to learn, "idiot
> mistake", despite having
> been told to take a step back and try and learn how the kernel works.
>
> Now we have to waste more maintainer time making sure nobody accidentally
> merges anything he sends.

Indeed; if you see any patches from Nick on other mailing lists which
you follow, it's a good idea to check and see if said patch is garbage
--- to date, his track record has been remarkably consistent.
But please do it in the nicest way possible, just in case he's a
reddit troll or some "journalist" trying to get headline bait by
getting a kernel developer to flame him to a crisp.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bdc3ae7221213963f438faeaa69c8b4a2195f491

quote:

diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
index 76441dc..dfd2243 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1238,7 +1238,7 @@ static ssize_t toshiba_kbd_bl_mode_store(struct device *dev,
int mode = -1;
int time = -1;

- if (sscanf(buf, "%i", &mode) != 1 && (mode != 2 || mode != 1))
+ if (sscanf(buf, "%i", &mode) != 1 || (mode != 2 || mode != 1))
return -EINVAL;

/* Set the Keyboard Backlight Mode where:

quote:

On Wed, Aug 6, 2014 at 9:59 AM, Andev <debian...@gmail.com> wrote:
> On Wed, Aug 6, 2014 at 9:56 AM, Nick Krause <xerofo...@gmail.com> wrote:
>
>> I have read the books you suggested, seems I was not doing the work in
>> the correct way.
>> I seem to be helping out with some traces for now.
>> Regards Nick
>>
>
> Nick, Are you suffering from autism? This is a genuine question as
> your behavior is really making lots of people think so. Please let us
> know so that we can act accordingly.
>
> --
> Andev
I do have aspergers.
Nick

# ? Aug 20, 2014 21:33

Shaggar: Apr 26, 2006

pram posted:

you can scale anything if you have a blank check.

i dont think netflix had it 'easier' but it's certainly 'easier' when your platform architecture is designed that way from the very beginning. instead of shoehorning some crufty piece of poo poo into teh clod

Netflix definitely has it easier. they're like 99.9999% reads and the writes they do aren't latency sensitive

# ? Aug 20, 2014 21:36

pram: Jun 10, 2001

A good observation from the shaggmeister

# ? Aug 20, 2014 22:34

ii oh el: Jan 9, 2007

raruler posted:

lurmickes

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bdc3ae7221213963f438faeaa69c8b4a2195f491
code:
- if (sscanf(buf, "%i", &mode) != 1 && (mode != 2 || mode != 1))
+ if (sscanf(buf, "%i", &mode) != 1 || (mode != 2 || mode != 1))
code:
(mode != 2 || mode !=1)

that's a tautological statement lmao. which makes the patch that much worse

# ? Aug 21, 2014 01:10

Notorious b.s.d.: Jan 25, 2003; by Reene

MononcQc posted:

Yes and no. I mean it's fairly obvious that cross-DC failover is hard as gently caress -- the link between DCs to even figure out you need to failover is likely less reliable than individual DCs -- but it totally matters if 10% of their requests fail.

10% of video streaming at their scale is a poo poo ton of load and bandwidth to shift around for the sake of it. It's big enough they need to strike deals with ISPs and carriers to keep delivering poo poo, and doing it while going over adversarial guys like Verizon trying their hardest to ruin their QoS. Sure they don't have a hard need for consistency and clients can retry (which clients can't by the way?), but there's no question that their problems are hard.

which clients can't retry? which clients can? in my career i don't think i've ever run into a client with robust failover. web browsers and lovely vertical market fat clients are the worst offenders

client robustness is a hard enough problem that netflix has published p. fancy open source libraries specifically for that

MononcQc posted:

IMO the main reasons poo poo can't scale are:
[list]
[*] 99% of the time it doesn't need to scale as much as you think it needs to

yeah idk man i live in a world where the "needs to" is "it would be awful nice if that once-a-week scheduled job could run hourly" or "it would be nice if this once a year job could be done monthly"

it's just not the same order of problem as serving thousands of discrete clients and not giving a gently caress about error rate. it is a different space entirely, and most of these problems don't benefit from distribution

# ? Aug 21, 2014 02:08

Notorious b.s.d.: Jan 25, 2003; by Reene

Cocoa Crispies posted:

crotchety cj stymie

that would be pram.

itt i am catching bullshit from both ends: cjs are mad that i think you should have real working automation, startup manchildren are equal parts astonished and disgusted that anyone thinks about operations in the first place

# ? Aug 21, 2014 02:10

pram: Jun 10, 2001

lol no you are catching poo poo because youre dumb

# ? Aug 21, 2014 02:35

pram: Jun 10, 2001

dumb

# ? Aug 21, 2014 02:35

theadder: Dec 30, 2011

accusing another yosposter of being a cj is a serious matter

# ? Aug 21, 2014 02:38

Brain Candy: May 18, 2006

pram posted:

you can scale anything if you have a blank check.

pram posted:

dumb

its u

# ? Aug 21, 2014 03:09

Tavistock: Oct 30, 2010

hack each others systems. first one wins

# ? Aug 21, 2014 03:10

pram: Jun 10, 2001

Brain Candy posted:

its u

# ? Aug 21, 2014 03:31

pram: Jun 10, 2001

wtf

# ? Aug 21, 2014 03:32

Bloody: Mar 3, 2013

pram posted:

lol no you are catching poo poo because youre dumb

# ? Aug 21, 2014 03:33

Bloody: Mar 3, 2013

pram didnt you have some other avatar for like a hot minute what happened to that

# ? Aug 21, 2014 03:33

VAGENDA OF MANOCIDE: Aug 1, 2004; whoa, what just happened here?; College Slice

P sure whoever's the one advocating for actually telnetting into a server deployment is the wrong one here jfyi

# ? Aug 21, 2014 05:40

pram: Jun 10, 2001

no one is advocating telnetting into anything

# ? Aug 21, 2014 05:45

Soricidus: Oct 21, 2010; freedom-hating statist shill

i miss rsh, it was so much faster than ssh

# ? Aug 21, 2014 09:14

jre: Sep 2, 2011; To the cloud ?

Shaggar posted:

Netflix definitely has it easier. they're like 99.9999% reads and the writes they do aren't latency sensitive

Shaggar was right

# ? Aug 21, 2014 10:11

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 11:02

MononcQc: May 29, 2007

Notorious b.s.d. posted:

which clients can't retry? which clients can? in my career i don't think i've ever run into a client with robust failover. web browsers and lovely vertical market fat clients are the worst offenders

client robustness is a hard enough problem that netflix has published p. fancy open source libraries specifically for that

But people in a web browser can and will retry. Enough that measures had to be taken in many places to protect against things like double-posting, re-submitting forms that were too old, etc.

Most programmed clients can retry by just calling the method they're in again or whatever. As far as I can tell, what makes it hard to retry is usually poor communication of the cause of error, or assumptions such that the user or caller doesn't really have a good way to know.

Here's a fun one if I turn off my wifi connection and try to pull a repo:

code:

$ git pull
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Little would point to 'bad connectivity' or prompt a retry. It pretty much looks like I managed to contact the endpoint but couldn't get it to cooperate. It's not easy, of course. Retrying is easy. Knowing if it's worth it to retry? That's a good bit harder and I'm not quite sure it's related to the quality of the client nearly as much as the protocol or overall design.

Then again, I'd like to read the netflix stuff and what they found was particularly hard.

Notorious b.s.d. posted:

yeah idk man i live in a world where the "needs to" is "it would be awful nice if that once-a-week scheduled job could run hourly" or "it would be nice if this once a year job could be done monthly"

it's just not the same order of problem as serving thousands of discrete clients and not giving a gently caress about error rate. it is a different space entirely, and most of these problems don't benefit from distribution

Yeah, that is a different form of scale. And it's one case where you won't really need cross-DC failover, which is what I was really focusing on. You often don't need that kind of scaling, if that makes my statement more accurate.

I just want to say that you never really not give a gently caress about error rates. Higher error rates is a shittier QoS (there's a cost to retrying), it's angrier customers, and so on. If your job is to serve thousands of discrete clients, error rates are one of the major metrics you have, because they pretty much correlate with how good of a job you're doing.

# ? Aug 21, 2014 13:05

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Linux: vim isn't moe

«‹›1097 »