Looks neat. My intranet is completely airgapped. Is your enterprise offering self-hosted? "Works with your infrastructure" on your webpage is very ambiguous.
Check out my above comment and feel free to ping me via email or twitter. Would love to get more detailed feedback from you and maybe try to change your mind!
Sorry but you're barking up the wrong tree. I use reprepro to host gpg signed packages (accessed over ssh so no ssl required) deployed from a vcs repo. The setup of the repo server itself is even handled through an apt package (hows that for self bootstrapping)
Even if I were interested, the obsession with ridiculous pricing structures means I could never use your service. Seriously how does 1 5mb package cost you more than 5 1 mb packages.
$100 a month gets me a hell of a lot of resources to host packages, and funnily enough it doesn't stop working or demand more money because the package count hit some arbitrary number.
Just for fun: man reprepro and search for 'corrupt' :)
You can use all your normal tools to upgrade, install, and remove packages as you normally would. So, for, Debian-based systems, apt-get upgrade, install, remove, etc all work as you expect.
We provide SSL, gpg, and fine-grained access control all out of the box. Fine-grained access control doesn't really exist with reprepro or createrepo or other tools and you'd have to build it yourself.
Also, you don't need to worry about backups, the numerous bugs in all the repo creation tools, and we have chef and puppet modules to help deploy this across your infrastructure.
We have support for multiple linux distributions in a single repo (quite a pain to deal with yourself) and best of all we also support pushing multiple versions of a single package to a repo -- something that reprepro does not support, but has been in progress for ~4 years [1].
I'm not a fan of this approach. Why did you build new, proprietary software instead of adding that feature to reprepo, for example? Why is packagecloud.io not giving back to the open source community when it's based on packaging tools developed for open source software? The fact that your software is proprietary means when you disappear, so does my infrastructure. I certainly don't like giving up basic user freedoms in the area of software packages, which has historically been open source.
DevOps here. I think you're stuck in market segment purgatory. SaaS/PaaS exist to remove pain points. People are either going to go PaaS (Heroku) or they're going to roll their own in AWS/Digital Ocean/etc.
I've already thought to myself, "I could roll this into the open source packages in question in 2-4 weeks in time, give back to the community, AND it helps my reputation." Consider how many others out there have seen this and thought the same.
As a tech professional, I don't think you're going to find much demand. As an entrepreneur, I wish you the best.
I thought it was pretty crazy that a tweak to prevent XFree86 from breaking on 64bit systems + support for the ELF small code execution model would later result in pthread_create overhead so large that creating threads on a P4 would be as slow as creating threads on a 386.
you just strip the debug symbols out (and put them somewhere safe). then write a .gnu_debuglink section to the stripped ELF binary with a CRC that matches the stripped symbols.
once something bad happens: you just take the core dump, the symbols you have tucked away, and you are able to debug just fine.
Thanks to you and others for jumping in and pointing this out! There's nothing better than being corrected when it means learning something new and solving a long-standing problem.
The question really is: how much data corruption is occurring that _does not_ cause world ending segfaults? THAT is what you need to worry about. Check yourself before you wreck yourself.
That is some amazingly selective memory corruption, homeboy. How whack is it that it is causing neither widespread segfaults nor widespread reports of creeping data corruption despite these VMs having logged billions of hours of CPU time in production all over the planet, dawg?
And yo check this: maybe this "fatal flaw" is actually just an edge case bug that isn't cropping up much in practice. Fo'shizzle!
And maybe we can drop the ridiculously asinine slang and douchey bravado, "bro".
registers are scanned, too. the bug is not that the ref is in a register. the bug is that there are no refs anywhere. not on the stack and not in any register.
This statement confused the heck out of me (wow! magic free memory) but of course, the pointers are being held to the contents of the memory, just not to the start of the object, which is what the GC cares about.
Perhaps the GC could be modified to track pointers not just to the head of object but to any address within it. Alternatively, C-coders working with Ruby could just say "I'm using this gc object" before calling C code.
I don't see this is a fatal flaw at all. Sounds like its just a bug. Now if, as many here assert, this bug is present all over the Ruby VM, then that's pretty unfortunate. Is that the case, or just hyperbole?
