New efforts!

[LadyVamp]

Err.  I'm not an authority on FreeBSD core development, but that seems to be a non-sequitur.  Docker - or more specifically libcontainer - is (as far as I'm aware) implemented on FreeBSD using jails.  Since jails are a necessary OS component for Docker implementation on FreeBSD, I don't see how FreeBSD can drop support for jails.  So I'm not sure what you mean when you say FreeBSD appears to be dropping jails.

Also, Docker support is still experimental (because of the 64-bit binary compatibility module stuff mostly) and I see no great rush to abandon jails in any FreeBSD haunt I wander through.

I'm not all that familiar with OmniOS.  It sounds very much like SmartOS which I'm somewhat more familiar with.  What would you say are the most significant distinctions between those two IllumOS children?

I'm not an authority on FreeBSD either.  Arch, RHEL/clones and Debian/children are my area of specialty.  Slackware to some degree.  I happen to have a good friend who is and is staying with FreeBSD 9 due to how jails are being handled in 10 and 11.  He did say that jails as he knew them were removed from 10 beta.  He thought the security wasn't a good.  Might have been just in beta only.

OmniOS and SmartOS both come from the same IllumOS world.  OmniOS seems to be geared more towards a traditional server and leaving it up to the sys admin to decide how things should be put together but has almost nothing in the repos.  You want MySQL?  Go download it, build it, and install it yourself.  A slackware lover from 20 years ago would likely feel right at home on OmniOS.  I've never worked with SmartOS but as I understand it, it takes a view of putting everything in either in zones or kvm VMs.

[LadyVamp]

This one drives me up a wall, but it feels like it's everywhere. It feels like every bit of code I inherit these days has been "tested" by seeing if it gives the expected results for one sample input (usually the most straightforward and trivial case there is), and once it does, someone marked it done and forgot it. I think I just about floored one guy earlier this week by giving him six different test sets for one problem, three of which I told him I expected to fail (but he had to make the system fail gracefully). I should probably check in on him at some point and see if the shock has worn off.

I tend to pick on our Java programmers for that very thing.  They talk of use cases and making the code handle just those.  I keep reminding them there's a test case called, "I will break your code any way I can, lil java programmer," aka use case idiot/black hat hacker.  The C/C++ programmers usually grin when I do that.  Most of the C/C++ devs are structured programming devs.

[Arcana]

I happen to have a good friend who is and is staying with FreeBSD 9 due to how jails are being handled in 10 and 11.  He did say that jails as he knew them were removed from 10 beta.  He thought the security wasn't a good.  Might have been just in beta only.

I've used jails in FreeBSD 9.x and 10.x, and even upgraded a couple from 9.x to 10.x.  As far as I'm aware, the primary difference between 9.x and 10.x is that there were a significant number of configuration semantics that were altered.  In particular, stuff from jail variables were moved to jail.conf, and stuff from jail.conf was moved to rc.conf, and some stuff that was default off became default on.  But I'm pretty sure any 9.x jail can be migrated to 10.x.

I recall there was some confusion about security, specifically about pf.  I think pf visibility changed between 9.x and 10.x inside the jails, but that could be restored to the original behavior with a config option.  Honestly, lots of issues surrounding jails comes down to the problem of importing into jails what they need without allowing them more access to those very things that can violate the jail.  Samba and raw sockets, for example.  I honestly can't keep track of them all, I keep a text file with all of them as a config doc.

[Codewalker]

\I happen to have a good friend who is and is staying with FreeBSD 9 due to how jails are being handled in 10 and 11.  He did say that jails as he knew them were removed from 10 beta.  He thought the security wasn't a good.  Might have been just in beta only.

I'm not sure what he thinks is changed about jails. The default way that they're managed by the startup scripts changed in 10, but the underlying jail technology is no different. Actually, the old way still works in 10. There's talk about removing it in 11, but it's not decided for certain yet, and since the startup process is just shell scripts, you could always copy that one over from 10 or write your own if you just can't stand jail.conf.

So I think it must be a misunderstanding or communication issue. FreeBSD focuses on evolutionary development, and one of their guiding principles is POLA - Principle of Least Astonishment. In other words, what will be the least surprising to existing sysadmins. It's in place specifically to prevent that kind of radical change. The few radical changes that were necessary (GEOM, atacam, the new usb stack) bent over backwards to maintain compatibility with existing tools and procedures.

[Vee]

I believe it was Arthur C. Clarke who said "any sufficiently advanced technological lingo is indistinguishable from MadLibs."

[LadyVamp]

I'm not sure what he thinks is changed about jails. The default way that they're managed by the startup scripts changed in 10, but the underlying jail technology is no different. Actually, the old way still works in 10. There's talk about removing it in 11, but it's not decided for certain yet, and since the startup process is just shell scripts, you could always copy that one over from 10 or write your own if you just can't stand jail.conf.

So I think it must be a misunderstanding or communication issue. FreeBSD focuses on evolutionary development, and one of their guiding principles is POLA - Principle of Least Astonishment. In other words, what will be the least surprising to existing sysadmins. It's in place specifically to prevent that kind of radical change. The few radical changes that were necessary (GEOM, atacam, the new usb stack) bent over backwards to maintain compatibility with existing tools and procedures.

Couldn't tell you.  He and I engage in frequent discussions about heavy weight vs light weight virtualization mostly.  He's more the idealist.  I'm the more pragmatic.  He has his ideas of how things should work.  I prefer they just work, not give me trouble, and update without issues.

I have tried FreeBSD 7, 8, 9, and 10.  I even keep a KVM VM built with 10.  But it's a base image.  FreeBSD 7, 8, & 9 worked quite well except I'd run into issues with ports.  Every time it would be with portmaster during an upgrade.  My experiences with 10 have been better since I now avoid the ports and just use packages.  It needs more speed with the disk subsystem.  My Debian file server is about twice as fast doing the same task.  Both use same underlying storage system.  Virtualized of course.  lvm thin on top of md raid configured as a raid 10 far using 4 disks on a KVM host.  I've gone through the zfs tuning guide.  Tried tuning it.  Did get better performance out of the VM but never could at least match the Debian VM even at 4x ram and proper tuning for an 8GB machine.  Also tried it with UFS but it still couldn't match the Debian fileserver. 

Since it sounds like you're a user of FreeBSD and have had better luck with it than I have, I would be interested to know how well bhyve works.  And how it compares to KVM or ESXi.  Where is it strong.  Where is it weak.  For my purposes, the hypervisor would need to be running some kind of advanced filesystem like ZFS in a raid 10 config on local disks.  zvols would be my preferred choice over qcow2 or raw images.  It would have little more than the hypervisor itself, a ntp server, and perhaps dns/dhcp/pxe/tftp.  DNSMASQ comes to mind.  And it should be able to run other hypervisors as guests with nested guests.

[adarict]

Testing is dull and boring; and slows the schedule down.

I hate it too, but I hate trying to fix something I wrote years ago. The best time to find and fix problems is immediately when a system is being designed and implemented. When schedule or resources make me shortchange testing thoroughly, I know I'm going to pay that price later, and multiplied over. Or someone will.

And please, leave your test and debugging instrumentation in the final code base.

One of the most annoying things I see where I work is, design the product for "Happy Path".  The product is specifically designed based on the use case of users doing exactly what they are supposed to do.  Then having to argue over nearly every bug that is found and prove that it is not an "edge case".  This was the reason for MULTIPLE products and enhancements to fall prey to things like SQL injections.  The very first thing I look at for any field that allows user input, is simply to try entering high ASCII codes, or even just things like a backslash.  I can't even count the number of times that has broken our programs.  Especially since it has happened so many times over my last 20 years with the company.  You MIGHT be able to excuse it back in 1996, but to still have programmers make mistakes like that in this day and age is ridiculous.

Every time i hear our designers or developers say the phrase Happy Path, I get this twitch in my eye.

[LadyVamp]

One of the most annoying things I see where I work is, design the product for "Happy Path".  The product is specifically designed based on the use case of users doing exactly what they are supposed to do.  Then having to argue over nearly every bug that is found and prove that it is not an "edge case".  This was the reason for MULTIPLE products and enhancements to fall prey to things like SQL injections.  The very first thing I look at for any field that allows user input, is simply to try entering high ASCII codes, or even just things like a backslash.  I can't even count the number of times that has broken our programs.  Especially since it has happened so many times over my last 20 years with the company.  You MIGHT be able to excuse it back in 1996, but to still have programmers make mistakes like that in this day and age is ridiculous.

Every time i hear our designers or developers say the phrase Happy Path, I get this twitch in my eye.

That is a failing I see in today's programmers coming out of colleges.  They start talking use cases.  They don't seem to think of the use case idiot/black hat hacker.  But, you know what's worse?  They might decide the best way to solve the arguments with you is to send you to the unemployment line.  The good news will be Karma will likely punch them very hard in the gut in the way of a breach of customer data some day.

Tell you what else I find from those programmers.  They can't seem to follow process.  They abuse systems not designed for what they throw at it.  They can't create requirements documents.  Never mind them being tangible requirements.  They keep trying to tell me how to do my job instead of telling me what inputs they will give and what outputs they want or what the system needs to do (think BigIP, iRules, etc here).  And then, of course, I become the blocker.

I say they could do away with you because that's exactly what the division of my company responsible for the website is trying to do to us.  We're a different division who happens to run the private cloud they use for complete feature testing.  I don't wish bad luck on them but will enjoy a quiet chuckle when their "great plans" fall over on them.

[adarict]

That is a failing I see in today's programmers coming out of colleges.  They start talking use cases.  They don't seem to think of the use case idiot/black hat hacker.  But, you know what's worse?  They might decide the best way to solve the arguments with you is to send you to the unemployment line.  The good news will be Karma will likely punch them very hard in the gut in the way of a breach of customer data some day.

Tell you what else I find from those programmers.  They can't seem to follow process.  They abuse systems not designed for what they throw at it.  They can't create requirements documents.  Never mind them being tangible requirements.  They keep trying to tell me how to do my job instead of telling me what inputs they will give and what outputs they want or what the system needs to do (think BigIP, iRules, etc here).  And then, of course, I become the blocker.

I say they could do away with you because that's exactly what the division of my company responsible for the website is trying to do to us.  We're a different division who happens to run the private cloud they use for complete feature testing.  I don't wish bad luck on them but will enjoy a quiet chuckle when their "great plans" fall over on them.

Luckily, I fall outside of the normal flow of development and QA.  Of course the drawback to THAT is, it is very easy for them to ignore me, even when they bring me in specifically to point out the things I think are wrong.  I make recommendations, and then get to see them ignore most of them.  The most important thing is hitting deadlines.  The whole QA process is messed up also, because no one wants to see large numbers of defects so tehy reclassify them as "enhancements".

It gets to you sometimes, especially when a decade ago we had a pretty darn good record of releasing code that worked even in the weirdest scenarios.  I had a QA person that worked for me, and one of his tests was to stick a penny in the keyboard to hold down random keys.  I encouraged my QA people to come up with all kinds of weird ad hoc testing  Well, now it would be considered ad hoc testing. Back then, even their ad hoc testing had to have reproducible steps in place so that I could assign any tester to do it.

Also, when you mentioned Big IP, it set off another twitch in my eye.  I hate that system so very much.  Mostly because our network and datacenter guys appear to have the bare minimum skills required to use Big IP.

[LaughingAlex]

That is a failing I see in today's programmers coming out of colleges.  They start talking use cases.  They don't seem to think of the use case idiot/black hat hacker.  But, you know what's worse?  They might decide the best way to solve the arguments with you is to send you to the unemployment line.  The good news will be Karma will likely punch them very hard in the gut in the way of a breach of customer data some day.

Tell you what else I find from those programmers.  They can't seem to follow process.  They abuse systems not designed for what they throw at it.  They can't create requirements documents.  Never mind them being tangible requirements.  They keep trying to tell me how to do my job instead of telling me what inputs they will give and what outputs they want or what the system needs to do (think BigIP, iRules, etc here).  And then, of course, I become the blocker.

I say they could do away with you because that's exactly what the division of my company responsible for the website is trying to do to us.  We're a different division who happens to run the private cloud they use for complete feature testing.  I don't wish bad luck on them but will enjoy a quiet chuckle when their "great plans" fall over on them.

When I worked as tech support I saw similar in the rare occasion I had a programmer on the line with one of the clients.  The person was so arrogant as to not listen to anything I suggested.  They never thought about how updates could also occasionally break something, or give me any concrete information about the problem they were having.

I also read about hubris: It's common among programmers.  It is an old saying I read in my classes somewhere a long time back, if the programmers wrote there own encryption algorithm, you knew it was 100% not secure.  Because they were not professional encryption experts.  They were more like to program something very commonly used by amateur or complete novices at encryption.  The reality was, they did not know anything about information security, because they are not specialized in it.  Just as the nazi's enigma matchine in the 1940s was compromised by the consistent tendency of nazi submarines to report the weather(which allies could see to) with the enigma encryptions made it easy for americans to decrypt it, so to do programmers make mistakes like that today.

[Arcana]

The very first thing I look at for any field that allows user input, is simply to try entering high ASCII codes, or even just things like a backslash.  I can't even count the number of times that has broken our programs.  Especially since it has happened so many times over my last 20 years with the company.  You MIGHT be able to excuse it back in 1996, but to still have programmers make mistakes like that in this day and age is ridiculous.

True story.  One of the bugs I found** in a version of Citrix Metaframe was that if you set the administrator password to something that started with a capital letter "S" the installation would fail.

Its so stupid and old of a bug you can't find it any more in Citrix's knowledgebase.  So what proof do I have that Citrix developers are stupid enough to do something like this?  Because they did it more than once:

https://support.citrix.com/article/CTX130473

Search that article for 64049.  That's the hotfix for the bug where logging fails if you set your SQL password to something that begins with a capital S.  Its the same freaking bug, ten years later, in a totally different part of a totally different software implementation, but affecting the same letter of the alphabet?

I can't even imagine how this bug even works mechanically, and they did it twice.



** If bugs documented their finder, I'm absolutely certain I would go down in history as finding the most ludicrous list of bugs in production software in all of history.  Not the largest or most damaging or most critical or most difficult to find.  Most ludicrous.  It wouldn't even be close.

[Biz]

** If bugs documented their finder, I'm absolutely certain I would go down in history as finding the most ludicrous list of bugs in production software in all of history.  Not the largest or most damaging or most critical or most difficult to find.  Most ludicrous.  It wouldn't even be close.[/i]

If he could still come around here, I'm sure Joshex would try to steal that label from you.

[Vee]

Ok, Arcana gets the "Most Ludicrous Bugs Found in Production Software in all of History by a Non-Beyonder" award.

[Arcana]

If he could still come around here, I'm sure Joshex would try to steal that label from you.

It doesn't count if you create the bug yourself before finding it.

[eabrace]

It doesn't count if you create the bug yourself before finding it.

[Arcana]

Here's a brain teaser of a bug.  A few years ago we started getting some odd behavior in one of our storage appliances (technically, a cluster of them).  The high availability system would not properly fail the modules over during routine maintenance.  However, it was impossible to reproduce the problem through testing.  We discovered that the problem would only happen if we stopped fiddling with the system and them come back to it after a long period of time.  Working with the vendor we were eventually told that it was a manifestation of a known problem for which a patch was coming out, but in the meantime we could temporarily work around the problem by manually inducing failovers at least every 49 days or more frequently.

It took me, oh, about two minutes of thinking about it to realize what the problem likely was (and I was right).  Hint: the appliances ran Plan 9.

[Kassandros]

Interval in milliseconds stored in a 32 bit integer?

49*24*60*60*1000 roughly equal to 2^32.

[eabrace]

Interval in milliseconds stored in a 32 bit integer?

49*24*60*60*1000 roughly equal to 2^32.

I was thinking the same thing.  Smells like a buffer overflow of some sort.

[Disected]

Sorry but can someone explain something to me, having a little trouble understanding, so i get that "City of Titans" is its own project and a spiritual successor to CoH, but about the other issue regarding the licensing being revived, is the licensing being revived meant for exclusive creative rights for CoT or to actually revive CoH in it's final state? Thank you for your help and if this question was dumb sorry.

[Angel Phoenix77]

Sorry but can someone explain something to me, having a little trouble understanding, so i get that "City of Titans" is its own project and a spiritual successor to CoH, but about the other issue regarding the licensing being revived, is the licensing being revived meant for exclusive creative rights for CoT or to actually revive CoH in it's final state? Thank you for your help and if this question was dumb sorry.

As i see it, the buyers will role the City of. ip into it's own company that will provide anyone who wants to release their own server can. It will be in its final official issue which is issue 23. Cot wants to have a connection to City of. however, at the moment they cannot.