In which Mott555 gets confused by Github
-
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.
-
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?
-
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.
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?
-
Like that, but for userland changes.
-
Gee whiz -- that's a
I wonder if some readelf or objdump wizardry could tease out the culprit relocations...
-
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.
-
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.
-
You're assuming the structure is opaque to the application using it, I'm not.
Huh?
I don't see how that's relevant.
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.
-
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.
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.
-
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.
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.
-
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.
-
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...
-
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.
-
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
tosvn+ssh://svn.company.com
. And deal with all the associated crap that comes with that.
-
You have my sympathies. Were you also in charge of SVN-user training and support during the transition?
-
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.
-
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
-
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.
-
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
-
-
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]
-
I charge high royalties.
-
I already give you my valuable time by watching your Let's Plays.
-
I charge high royalties.
Here, have a bottle of Stawski Zytnia. That should cover me indefinitely.
-
It should immediately after I receive it.
-
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 ismono-xbuild
. They are pulled in viamono-devel
, which is inRecommends
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 inSuggests:
and therefore not part of default Monodevelop install.
-
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
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?
-
monodevelop
does depend onmono-runtime
(at least in Debian and Ubuntu where I checked).If Mint failed to install that, it is a big bug.
-
That's irrelevant packages.
- I snipped the full list. It was many tens of lines long.
- That spew is from Ubuntu 15.04.
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.
-
-
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.
-
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.
-
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.
-
Description: Gentoo
Is it better than it was a few years ago? I hated indescribably for the time I used it.
-
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.
...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?
-
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.
-
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]