|
Subjunctive posted:ship stuff people use for more than a year more innovation for me
|
#
?
Jan 14, 2015 05:23
|
|
|
|
| # ? May 12, 2024 11:46 |
|
|
Subjunctive posted:but don't bitch out with "the pom says what version" and hope that the maven hivemind will have the same thing waiting for you, and that there aren't javac or jvm changes. if you're serious about reproducibility, you check in the toolchain and all deps. every version of every compiler that MSFT has ever used to ship something outside the company is in their big repository of all-knowingness. need to build *exactly* XP SP1 with a single value changed? yeah, they can do that, and they can count on the fact that they did it. idrgi just check / into git
|
|
#
?
Jan 14, 2015 05:25
|
|
|
MALE SHOEGAZE posted:more innovation for me 
|
|
#
?
Jan 14, 2015 05:26
|
|
|
MALE SHOEGAZE posted:more innovation for me you can keep doing new stuff, but when you need to go back and ship a security update or small bug fix to be compatible with some OS service pack, you want to know you're starting from the same result. all of this stuff is simplified dramatically if nobody cares that much about your thing
|
|
#
?
Jan 14, 2015 05:26
|
|
|
MALE SHOEGAZE posted:idrgi just check / into git images of the build host are a decent solution if you can manage them and you make sure you keep a copy of the hosting virtualizer somewhere safe
|
|
#
?
Jan 14, 2015 05:27
|
|
|
http://en.wikipedia.org/wiki/Vesta_%28Software_configuration_management%29 
|
|
#
?
Jan 14, 2015 05:51
|
|
|
Subjunctive posted:but don't bitch out with "the pom says what version" and hope that the maven hivemind will have the same thing waiting for you, and that there aren't javac or jvm changes. if you're serious about reproducibility, you check in the toolchain and all deps. every version of every compiler that MSFT has ever used to ship something outside the company is in their big repository of all-knowingness. need to build *exactly* XP SP1 with a single value changed? yeah, they can do that, and they can count on the fact that they did it. i'm sure they also have piles of soundblasters! to make sure they can reproduce ninety percent of the crash bugs like this sounds smart and thorough until you realize the implicit dependencies are not stable at all. sure, save all the things 'cause storage is basically free but just because you can get the same bytes out doesn't mean you actually get the same results
|
|
#
?
Jan 14, 2015 06:00
|
|
|
Brain Candy posted:i'm sure they also have piles of soundblasters! to make sure they can reproduce ninety percent of the crash bugs and so we should abandon all source control
|
|
#
?
Jan 14, 2015 06:18
|
|
|
the argument for source control is that although having the same bytes around helps a lot with getting the same results, and the more things that are kept inside source control, the more likely you are to get the same results. your argument is source control is like keeping soundblaster cards around, as although you can get the same bytes out doesn't mean you actually get the same results you are an idiot, hth
|
|
#
?
Jan 14, 2015 06:21
|
|
|
Subjunctive posted:if you're serious about reproducibility, you check in the toolchain and all deps. this works real well if you use a source control system with subtree checkouts, large file support, and a bunch of other things many don't
|
|
#
?
Jan 14, 2015 06:26
|
|
|
Brain Candy posted:like this sounds smart and thorough until you realize the implicit dependencies are not stable at all. sure, save all the things 'cause storage is basically free but just because you can get the same bytes out doesn't mean you actually get the same results what's the uncapturable source of non-determinism you have in mind? CPU deviation? race conditions in the toolchain? you do have to take some things as axiomatic, but you can take many fewer things thusly if you capture all the input bytes to the system. (I would be surprised if it's actually not fairly common for someone to reach back 10 years to roll a small fix for Morgan Stanley or DOD or someone with low change tolerance and long deployment cycles. I work with a guy who'll know, I'm curious now.)
|
|
#
?
Jan 14, 2015 06:38
|
|
|
change is my axiom of choice
|
|
#
?
Jan 14, 2015 07:08
|
|
|
Subjunctive posted:if you're serious about reproducibility, you check in the toolchain and all deps. ALL THE DEPS if you depend on a linux, have an ISO checked in. ALL the deps.
|
|
#
?
Jan 14, 2015 07:11
|
|
|
rotor posted:ALL THE DEPS https://blog.torproject.org/category/tags/deterministic-builds
|
|
#
?
Jan 14, 2015 07:15
|
|
|
rotor posted:ALL THE DEPS last time i tried checking a linux ISO into github i got banned forever!
|
|
#
?
Jan 14, 2015 07:16
|
|
|
MALE SHOEGAZE posted:change is my axiom of choice the axiom of choice is my copilot
|
|
#
?
Jan 14, 2015 07:37
|
|
|
Luigi Thirty posted:last time i tried checking a linux ISO into github i got banned forever! i think you know the solution here
|
|
#
?
Jan 14, 2015 07:46
|
|
|
Brain Candy posted:but just because you can get the same bytes out doesn't mean you actually get the same results this sure is the thread for you
|
|
#
?
Jan 14, 2015 07:49
|
|
|
Subjunctive posted:all of this stuff is simplified dramatically if nobody cares that much about your thing I worked on a project like this and it was incredibly liberating. just fuckin do whatever, nobody actually cares.
|
|
#
?
Jan 14, 2015 07:51
|
|
|
the electrons in your computer are constantly changing, a computer u got 7 years ago will literally be made of different bytes than it was made of when you bought it. so really nothing is ever deterministic
|
|
#
?
Jan 14, 2015 07:53
|
|
|
electrons are the worst in their teens
|
|
#
?
Jan 14, 2015 07:57
|
|
|
MALE SHOEGAZE posted:the electrons in your computer are constantly changing, a computer u got 7 years ago will literally be made of different bytes than it was made of when you bought it. so really nothing is ever deterministic you never step in the inputstream twice
|
|
#
?
Jan 14, 2015 07:59
|
|
|
my electron is being willful and dyeing it's hair red
|
|
#
?
Jan 14, 2015 13:56
|
|
|
Subjunctive posted:what's the uncapturable source of non-determinism you have in mind? CPU deviation? race conditions in the toolchain? everybody like to pretend that hardware is equivalent for santity but let's look at what you need to run microsoft XP SP1 Snipped from Minimum specs for XP Pentium 233-megahertz (MHz) processor or faster (300 MHz is recommended) At least 64 megabytes (MB) of RAM (128 MB is recommended) At least 1.5 gigabytes (GB) of available space on the hard disk Video adapter and monitor with Super VGA (800 x 600)or higher resolution Sound card unless i really do have vault of soundblasters!, I'm going to use more modern hardware and pray the first three have vastly faster have different speeds and latencies. they'll soon be a point where i can't even buy a HDD that behaves like that spinny piece of poo poo. vastly different random access patterns. video card and sound card? ffs, microsoft changed the entire driver model in vista because because theses POSs were causing most of the crashes. beep-boop the bytes are the same doesn't mean poo poo if you don't have tests that define what the things you care about being the same are
|
|
#
?
Jan 14, 2015 14:59
|
|
|
idk about msft but i think i read somewhere that apple maintains old machines for regression testing. wouldn't be surprised if msft does the same. also don't they bump up min requirements with patches sometimes? this could be why but idk, idk.
|
|
#
?
Jan 14, 2015 15:06
|
|
|
tef posted:the argument for source control is that although having the same bytes around helps a lot with getting the same results, and the more things that are kept inside source control, the more likely you are to get the same results. actually i'm arguing that if think that saving all the bytes is sufficient for being 'serious', you are mistaking precision for accuracy or that this one of the things that gets exponentially harder and more expensive to do for tinier tinier increases in certainty and it Depends. and that i'm tired of nerds who have pick a spot with costs they feel at comfortable sanctimoniously defending that as tradeoff as the only one that anyone would ever need
|
|
#
?
Jan 14, 2015 15:16
|
|
|
when the costs are effectively nothing you can still make the claim "you should do at least this much" and be objectively correct. you seem to think that people are also saying "but don't put any more effort into it than we do", when that's really not what they're talking about
|
|
#
?
Jan 14, 2015 15:43
|
|
|
Jabor posted:when the costs are effectively nothing you can still make the claim "you should do at least this much" and be objectively correct. look at this cool thing here, i'm not disagreeing in the practical Brain Candy posted:sure, save all the things 'cause storage is basically free i am arguing about what it actually gets you, which is not as much as it seems
|
|
#
?
Jan 14, 2015 16:13
|
|
|
C# is really cool and good
|
|
#
?
Jan 14, 2015 17:57
|
|
|
Brain Candy posted:actually i'm arguing that if think that saving all the bytes is sufficient for being 'serious', you are mistaking precision for accuracy I don't understand what you're saying here, so I'll just restate the point: you save and version all your dependancies because then you can always reproduce your builds. that's it. if you want to punt on the ability to repro past builds, or to rely on the kindness of strangers to host your dependancies, well that's your call but it's dumb imo.
|
|
#
?
Jan 14, 2015 18:07
|
|
|
rotor posted:I don't understand what you're saying here, so I'll just restate the point: check in your build vm to source control
|
|
#
?
Jan 14, 2015 20:26
|
|
|
on stackoverflow, why are the search results when you make a new post extremely good, but the actual search feature extremely bad.
|
|
#
?
Jan 14, 2015 23:56
|
|
|
PleasureKevin posted:on stackoverflow, why are the search results when you make a new post extremely good, but the actual search feature extremely bad. Because the only posts that occur on stack overflow are posters telling other posters that their question was already answered
|
|
#
?
Jan 15, 2015 00:43
|
|
|
PleasureKevin posted:on stackoverflow, why are the search results when you make a new post extremely good, but the actual search feature extremely bad.
|
|
#
?
Jan 15, 2015 00:47
|
|
|
MALE SHOEGAZE posted:Because the only posts that occur on stack overflow are posters telling other posters that their question was already answered my favorite is when the top result on google for a question is a forums exchange with the only answer being "google it dumbass"
|
|
#
?
Jan 15, 2015 00:56
|
|
|
Subjunctive posted:but don't bitch out with "the pom says what version" and hope that the maven hivemind will have the same thing waiting for you, and that there aren't javac or jvm changes. if you're serious about reproducibility, you check in the toolchain and all deps. every version of every compiler that MSFT has ever used to ship something outside the company is in their big repository of all-knowingness. need to build *exactly* XP SP1 with a single value changed? yeah, they can do that, and they can count on the fact that they did it. if you need a very specific artifact, you have an artifact repository containing every artifact you have ever built if you need to update a very old version of the software, you specify a javac/jvm version to use. every patchlevel ever is available in oracle's archives what you never need to do: check your binaries into your source control
|
|
#
?
Jan 15, 2015 03:26
|
|
|
Notorious b.s.d. posted:if you need a very specific artifact, you have an artifact repository containing every artifact you have ever built what if i call it version control instead of source control, then can i check my binaries in?
|
|
#
?
Jan 15, 2015 04:23
|
|
|
what if the artifacts are binaries
|
|
#
?
Jan 15, 2015 04:24
|
|
|
I think I may have finally graduated from terrible to merely bad today. At a job I've been at a week and a day I did a hour long presentation on intro to git, since our architect decided to move to git and he's 4 hours away, and I'm the guy in the office teaching people the verbs and work flows and helping set poo poo up and fixing merges. Either that, or I just jabbered on for a loving hour and used that d3 visualization tool to lure people into the pit of hell. The best poo poo to explain to newbies is why we need -m 1 when we're reverting a merge (because we need to pick which leg of the merge to revert to for a given branch), what HEAD is, why the architect made a branch called HEAD when he's supposed to be smart, and that a revert commit is itself a commit to show the revert. But, by god, I got through it, and made sure they don't go loving with resets or rebase yet. I then spent 2+ hours hand holding bitbucket and cloning repos, whee.
|
|
#
?
Jan 15, 2015 04:56
|
|
|
|
| # ? May 12, 2024 11:46 |
|
|
every time i see one of those talks, it just further reinforces my belief that git is for people who really like version control and want to dedicate a few hours per week to it. makes sense if you're linus, but most developers don't want (and shouldn't need) to know git details beyond "here's a translation chart for the subversion command set, go nuts! btw branching works now"
|
|
#
?
Jan 15, 2015 05:00
|
|