In which Mott555 gets confused by Github

blakeyrat

I hotdeploy code changes all the time and it works fine

If it's something like a web API where each page load is basically a new process that terminates when the page is served, that's probably fine.

If it's, say, the library decoding PNG images (the kind likely to need patching due to a security hole), now you have a new library which may behave differently and have different data structures from the previous one being "hot-swapped" into place. The program that was using the old data structure passes one back into the new library and crashylvania.

Jaime

@tarunik said:

Wild idea: what would it take to make a loader that can "hot reload" a shared object into a running process after it's been changed on disk?

You mean KSplice?

tarunik

@blakeyrat said:

If it's, say, the library decoding PNG images (the kind likely to need patching due to a security hole), now you have a new library which may behave differently and have different data structures from the previous one being "hot-swapped" into place. The program that was using the old data structure passes one back into the new library and crashylvania.

At that rate with the data structure changes -- the new library is violating its interface contract anyway, so all bets are off even if you reload the program with the new library in place.

@blakeyrat said:

or they had to shut down every service using the library and restart them (equivalent to rebooting).

For many Linux systems, this is very much not equivalent to a reboot. Hint: the package manager will restart daemons on the fly ;) (at least in the case of dpkg)

Which would you rather have: a print server that had a five-second blip in print services (barely noticeable) or a two-minute outage for a reboot (something that's likely to draw at least one raised eyebrow in a large office) due to a patch to the PDF rendering library the print server is using?

tarunik

Like that, but for userland changes.

tarunik

Gee whiz -- that's a

I wonder if some readelf or objdump wizardry could tease out the culprit relocations...

blakeyrat

@tarunik said:

At that rate with the data structure changes -- the new library is violating its interface contract anyway, so all bets are off even if you reload the program with the new library in place.

???

How?

If I ask my PNG library: "hey give me a blah that represents a PNG", then I can guarantee for the runtime of my application that that blah can be fed back into the library at any time.

If you allow runtime patching of DLLs, you've now broken that guarantee. Now you feed the blah back in and crashytowne.

Oh wait, are you thinking about a situation where that application might save the blah to disk instead of serializing it properly? Considering the blah probably has about 45743 pointers in it that can't be reasonably serialized, I'm guessing that's not a real issue here in reality, not in crazy delusional Linux-user land.

tarunik

@blakeyrat said:

If you allow runtime patching of DLLs, you've now broken that guarantee. Now you feed the blah back in and crashytowne.

You're assuming the structure is opaque to the application using it, I'm not. If the application is feeding the library a structure (or modifying/using a structure given back to it by the library) and that structure changes in a non-trivial way, then hotpatching or not, you're still in crashytown because your application doesn't have the correct offsets for that structure's fields compiled into it any longer.

blakeyrat

@tarunik said:

You're assuming the structure is opaque to the application using it, I'm not.

Huh?

I don't see how that's relevant.

@tarunik said:

If the application is feeding the library a structure (or modifying/using a structure given back to it by the library) and that structure changes in a non-trivial way, then hotpatching or not, you're still in crashytown because your application doesn't have the correct offsets for fields compiled into it any longer.

Well duh.

But the point is: if I got that structure from the library in the first place, I can pass it back unmodified to the same library and everybody's got all their ducks in a row.

I'm not talking about an application that digs into someone else's data structures and fucks around, everybody knows that's crashytowne frolics, duh. Double-duh.

I'm talking about programs innocently using the library as expected and directed who now have super-crashy-world problems because the library version shifted out from under them.

tarunik

Apparently you've never seen an interface contract that included a data structure in it -- I thought that was the common use-case, and that opaque structures, while nice in some ways, were not so common in comparison.

@blakeyrat said:

I'm talking about programs innocently using the library as expected and directed who now have super-crashy-world problems because the library version shifted out from under them.

BTW: for honest-to-goodness security fixes, data structure changes are rather rare: 56 of 64 kernel patches analyzed by the original Ksplice developers in their paper did not involve any changes to data structures.

As to the other 8? The Ksplice patches include a small piece of fix-developer-written migration code in that case to deal with this, so it's not an intractable problem.

blakeyrat

@tarunik said:

Apparently you've never seen an interface contract that included a data structure in it -- I thought that was the common use-case,

It might be a common use-case, but I wouldn't say the.

Think about the Win32 API for example: working with that is basically nothing BUT holding on to data structures you're not supposed to be touching.

@tarunik said:

As to the other 8? The Ksplice patches include a small piece of fix-developer-written migration code in that case to deal with this, so it's not an intractable problem.

Sounds great for the shitty Linux ecosystem where everything crashes because it's all shitty anyway, but I doubt you'll see Microsoft adopting anything like that.

tarunik

@blakeyrat said:

Think about the Win32 API for example: working with that is basically nothing BUT holding on to data structures you're not supposed to be touching.

Anything that's actually backed by a real NT kernel object is more akin to a *nix file descriptor, anyway. Granted -- it seems that you're overestimating the number of "OMG WE NEED TO PATCH THIS LIBRARY THAT'S USED BY LITERALLY EVERYTHING" security fixes (your PNG-file-reader-library-hole doesn't count, for one) out there.

PJH

@bugmenot said:

Is there official SVN Cabal-maintained software for doing remote backups for when you have full access to a repo, but cannot acquire shell access to the server which contains the repo?

Oxymoron. Full access implies shell access. Or, if you prefer, if you don't have shell access, that is not full access.

So, in answer to your question, no.

HTH, HAND, etc, et alia...

bugmenot

@PJH said:

Full access implies shell access...

Nah.

I guess you've not administered an SVN server. You can prevent folks from reading and/or writing to certain paths within a repo. See: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html

Though, I guess I could have been more precise. All -I guess- you'd need would be full read access to a repo.

PJH

@bugmenot said:

I guess you've not administered an SVN server.

[root@NCL-DEVELOPER ~]# wc -l /var/www/svn/company/conf/authz
119 /var/www/svn/company/conf/authz
[root@NCL-DEVELOPER ~]#

I have.

Sadly.

It was my job to "change the URLs" from svn://svn.company.com to svn+ssh://svn.company.com. And deal with all the associated crap that comes with that.

bugmenot

You have my sympathies. Were you also in charge of SVN-user training and support during the transition?

PJH

@bugmenot said:

Were you also in charge of SVN-user training and support during the transition?

Have a guess.

The copious documentation boiled down to:

Configuration - put the following in ~/.ssh/config:
host svn.company.com
	ForwardX11 no
	user svnclient
	identityfile ~<user>/.ssh/<user.name>_rsa
To update your local code paths without having to scrap and recheckout, run:
cd $SRCDIR
svn switch --relocate svn: svn+ssh:
svn update
In future, instead of using
svn <feature> svn://svn.company.com/rest/of/path
use
svn <feature> svn+ssh://svn.company.com/rest/of/path

That was over a year ago.

Guess what I do between fixing bugs and creating new features?

[spoiler]Actually sorting out peoples' access so that they may create new bugs; well it takes me about 3 minutes total to grant access. That should be the end of it. But no...

Explaining the documentation in words of one syllable or less, while holding their hand, takes a bit longer for the less brighter of our new starters. And the ones that have broken their setup. Again.[/spoiler]

It's not all bad: Fortunately, for me, the people concerned generally aren't in my department, so the new things that are created in that spoilered bit aren't my department's responsibility.

That department simply use the same server.

I merely grant/rescind access to (bits of) it.

Jaloopa

@powerlord said:

One of the benefits of using a package manager (standard on Linux) is that it knows which packages are dependent on a library

Last time I used a package manager it was to install MonoDevelop. It didn't install Mono, which you'd think would be a fairly obvious dependency

Bulb

@Jaloopa said:

Last time I used a package manager it was to install MonoDevelop. It didn't install Mono, which you'd think would be a fairly obvious dependency

Mono runtime itself is, because monodevelop is written in it.

However mono compiler and stuff is not, because:

It supports the following languages: C, C++, C# (1.0, 2.0 and 3.0), Vala, Boo, Java, Nemerle, ILasm, ASP.NET and VB.NET

Not all of those use mono, so mono-devel is not a dependency. It should be a recommendation and that it indeed is—and default setting of aptitude is to install recommendations.

Jaloopa

All I know is I installed MonoDevelop from the Mint application installer thing and it wouldn't open until I also searched for Mono and installed that

OffByOne

@blakeyrat said:

crashylvania

I like this word. I'm going to use it from now on.

bugmenot

@Jaloopa said:

All I know is [T]he Mint application installer thing [didn't have Mono as a dependency for Monodevelop].

That sucks. Either the Mint packagers seriously fucked up, or there's an "Also install recommended packages" checkbox in the Mint application installer thing that needs to be checked. Both Ubuntu and Gentoo Linux know that Monodevelop has a dependency on Mono:

# lsb_release -d
Description:  Ubuntu 15.04

# apt-get install monodevelop
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
[snip]
  libmono-2.0-dev  libmono-accessibility2.0-cil libmono-accessibility4.0-cil
[snip]

# lsb_release -d
Description:  Gentoo Base System release 2.2

# emerge -p monodevelop
These are the packages that would be merged, in order:

Calculating dependencies... done!
[snip]
[ebuild  N     ] dev-lang/mono-3.2.8  USE="nls pax_kernel -debug -doc -minimal -xen" 
[snip]
[ebuild  N     ] dev-util/monodevelop-3.0.2-r1  USE="git subversion"
[snip]

blakeyrat

I charge high royalties.

OffByOne

I already give you my valuable time by watching your Let's Plays.

FrostCat

@blakeyrat said:

I charge high royalties.

Here, have a bottle of Stawski Zytnia. That should cover me indefinitely.

blakeyrat

It should immediately after I receive it.

Bulb

@bugmenot said:

libmono-2.0-dev libmono-accessibility2.0-cil libmono-accessibility4.0-cil

That's irrelevant packages. The C# compiler is mono-mcs and the build system is mono-xbuild. They are pulled in via mono-devel, which is in Recommends of Monodevelop. In Debian and Ubuntu and since Mint is Debian-derivative as well, presumably there as well. So either Mint application installer has wrong default (which would be a bug), or @Jaloopa changed it, in which case PEBKAC.

Edit: I should add that VB.NET compiler is mono-vbnc and that is only in Suggests: and therefore not part of default Monodevelop install.

Jaloopa

@Bulb said:

or @Jaloopa changed it

I changed nothing. Installed the OS, installed a single application through the package manager, application refused to open. Wonderful open source usability

@Bulb said:

The C# compiler is mono-mcs and the build system is mono-xbuild

Are either of them the Mono runtime? You know, the runtime required to run the application, i.e. a concrete dependency that wasn't installed?

Bulb

monodevelop does depend on mono-runtime (at least in Debian and Ubuntu where I checked).

If Mint failed to install that, it is a big bug.

bugmenot

@Bulb said:

That's irrelevant packages.

I snipped the full list. It was many tens of lines long.
That spew is from Ubuntu 15.04.

@Bulb said:

If Mint['s graphical package installer] failed to install that, it is a big bug.

I've run into my fair share of never-used-by-anyone-who-cares-to-maintain-them buggy GUIs over top totally solid package managers before. I don't understand how they get shipped, but they do.

FrostCat

@blakeyrat said:

It should immediately after I receive it.

PM me your address.

mott555

Back to the original topic, and to provide some closure, using SVN with Github seems to work just fine and doesn't require ANY shenanigans whatsoever to make things Just Work.

accalia

True, however some advanced features of git do not map to SVN so you may not be able to do everything via SVN.

it should be good enough to get you through the day to day stuff though.

Yamikuronue

@accalia said:

some advanced features of git do not map to SVN

Like blame. They both do it, but you can't run blame on a git repo checked out via svn from github.

swayde

@bugmenot said:

Description: Gentoo

Is it better than it was a few years ago? I hated indescribably for the time I used it.

bugmenot

@swayde said:

Is it better than it was a few years ago?

I've been using Gentoo for -fuck me, I'm old- a decade. If you tell me what you hated, I can probably tell you if it's no longer there.

@mott555 said:

...SVN with Github seems to work just fine and doesn't require ANY shenanigans whatsoever to make things Just Work.

It's good that you found something that worked. From your OP, it sounds like the only problem you had with git was a misattributed commit (as found by accalia here) , which was a huge pain to fix. Do I have that right?

mott555

@bugmenot said:

It's good that you found something that worked. From your OP, it sounds like the only problem you had with git was a misattributed commit (as found by accalia here) , which was a huge pain to fix. Do I have that right?

Basically. Plus my brain is permanently set in SVN ways.

ben_lubar

GitHub has SVN support for the same reason that programmers use compilers.

[spoiler]They're fun to write and can introduce bugs that are not part of the program.[/spoiler]