Forgot your password?

typodupeerror

Comment: Imagination? (Score 0) 279

by cpct0 (#36195760) Attached to: Apple: an 'App Store' Is Not a Store For Apps

Funny how on Mac it always was Applications, on Win it was always Programs, on Lin it was always Software, and then you got all the different variations for all the platforms everywhere. Some use Ware, some use Soft(pedia for example).

Then Apple starts using Apps, coins the App Store to go there, gets the most talked about platform, and somehow it now has become "common sense" to use Apps for everything, and the only place to get an App is on the App Store.

Imagination, people ... come on! It's a freaking term, coin your own! Soft Store, Get-A-Ware, don't know what. And although I understand Apple in their stance, I find it funny and ridiculous. It reminds me of Microsoft Bookshelf.

Comment: Re:I find it odd (Score 2) 244

by cpct0 (#36110534) Attached to: Google Engineers Deny Hack Exploited Chrome

You see, that's exactly the kind of things people should never have to hear about a product. If I get a product, whether at $0 or $10,000, it should always be responsible for its own integrated tools.

Let say I buy an integrated specialized medical database using Oracle as backend. First, I shouldn't really have to care it uses Oracle. Is the product working or not? Yes or no. The reason why a specific request would fail "because its an Oracle bug" is moot, the vendor decided to use Oracle, it should vouch by it.

Let say again I buy M$ Outlook. It uses M$ Jet as its backend. Should I really care? Absolutely not! Actually, you learn about that part when you (used to) go over 2GB and the system would balk with a corrupted archive. To have the vendor tell me it's a Jet bug shouldn't be taken seriously, they chose to use it, they live with the limitations, and it now becomes an Outlook bug.

Same for Chrome. I decide to install Chrome on my computer. It uses WebKit. It comes bundled with multiple DLLs and tools, D3DX, Gears, AVFormat and so on. Some are even signed by Google themselves, some files even contain Flash provisions inside them. They should vouch for what they have, and actually consider their bundled tools as part of their software, no matter what.

(extrapolation) I wonder how it would go with my mom, trying to make her understand that she uses a software she installed, but the fact her computer became infected with malware is because of some extraneous tool she unwittingly installed at the same time she installed Chrome, is part of the default package, and is bugged down. :) She'll remove Chrome and never go back to it because it's ITS fault. :)

Comment: I find it odd (Score 1) 244

by cpct0 (#36107420) Attached to: Google Engineers Deny Hack Exploited Chrome

A company takes care to actually go through code, assembly, source, any means really, figure out a hack that's specific to Chrome ... and somehow, they are the ones misunderstanding the code. Somehow that answer doesn't satisfy me :)

Also, the answer would be equivalent to having my code use Sqlite as a dll, I bundle it in my package, I install it, it's mine ... but somehow when someone hacks my application through a (very theoretical - example only! move on trolls ;) ) sqlite bug, I would have the exit door saying "oh yes, you can hack my app, it's defenseless, but it's not my fault, it's sqlite here! *points*"

Please ... Chrome ... You bundle it, you vouch by it, you got hacked, you recognized, don't start making excuses please. It's no big deal, it's only a bug, like there are countless in ALL applications throughout the world.

Comment: Re:Wakeup call US? (Score 1) 174

by cpct0 (#35991592) Attached to: Playstation To Restore Services This Week

Mmm, well, there is the PCI standard that's supposed to protect you against such things, disallowing ANY kind of credit card number keeping. I guess Sony weren't PCI compliant, and I guess this is why they are being checked by all these groups, because such thing should've never happened, at least for the CC#. I know, I had to go through that test last year, and it's quite secure.

For the account info, that's something else, they screwed up and that's it. Let me guess, their passwords were sent through a SHA-1 or some other crappy password verifier. :)

Comment: Re:Not up to the standards of Japan (Score 4, Insightful) 111

by cpct0 (#35855240) Attached to: A "Throne" Fit For a Tech King

It actually is up that standard ... and Toto, the famed washlet makers are actually producing these in USA too ... you simply need to look them up.

I find it funny to see this coming over everywhere on the Intarwebz. At least Kohler knows their way up the social media / blogosphere / viral marketing.

Comment: Re:Late Again? (Score 1) 162

by cpct0 (#35791290) Attached to: Microsoft TouchStudio Uses Phone To Program Phone

For me, it strangely reminds me of Hypercard ... and thus of current Mac OS X Automator. If you want even easier, I'd even go to Quartz Composer. Yet again things pioneered by Apple. I wouldn't create a full 3D game using that scripting system, it's totally different and not meant for the same thing.

People simply don't understand high-level versus low-level; both has merits.

Comment: Here we go again (Score 1) 500

by cpct0 (#35356282) Attached to: The Decline and Fall of System Administration

Is this the old geezer versus the new wet diapers yet again? (trying to be as evil on both sides ;) )

There are new technologies and we should embrace them. I am not a proponent of VMs, I don't like them in general, but I do see its uses and it's very effective. Like in C++, you got STL, with very similar and nearly interchangeable std::vector, std::list, std::deque and so on (and not talking about boost or 3rd parties here). You need to know when to apply them or else you'll get problems. Well, in the '10s, you have the same ridicule amount of technologies available to sysadmins, and you need to know when to apply it. That's the new Sysadmin job, not only know that you can code one in bash with grep, awk, echo, while read, pipes and rsync, but actually know there is a package all neatly made for you, available at your fingertips with a simple apt-get (or yum).

I keep my computer tidied-up, I love to know what runs where. Even then, I do a "spring cleaning" once every year, reinstalling everything. And incredibly, my computer runs faster and more efficiently. Why? new /etc defaults, new parameters, new software, old clinging software, things that are nearly impossible to update. Same for the files. Seriously, in today's computers, we get hundred of thousands of files, most of which have some arcane use we couldn't care less, but are necessary for some kind of weird reason. I'm a sysadmin, and I don't pretend to want to know all these files.

I read the article, and yes, there are things that are changing, and seriously, I do respect the One person who can understand the Sendmail configuration files... oh I'd even be impressed with the M4. :) And when there is a problem, I want to know why, because I love to learn. But then ... there are prerogatives, time constraints, servers need to be up, people need to work, and we have all these magnificient tools that will enable every computer to be segregated in their private little VM world (to return to that main article). So should be simply shrug, laugh and go back to The Ancient Ways? You can keep you "vi" editor, leave me my "vim", please. :)

Comment: Re:Not better than the others (Score 1) 705

by cpct0 (#35283778) Attached to: Why You Shouldn't Reboot Unix Servers

It scales horribly
It takes more work
It takes more time down the end ... but then, I don't have a %(#)load of users sending me e-mails, calling me (off-site), coming to see me in real life, and I don't have to send a message to all the clients and users saying it's known, and I don't have the company managers telling me they're in a crunch or whatnot.

95% of users coming to my desk in these mere minutes a server is down:
- hi
- hi. Yes?
- how are you?
- not too bad, you?
- going well. I got a question for you?
- yes?
- Are you working on whatever server?
- yeah, it's down. Restarting it now, there might be further downtime later on if I see a solution, and it might require further downtime. Hopefully not.
- oh ... ok, thanks
- no sweat.

So I'm sorry, I'm really inexperienced I guess, I just work with active servers with users happily churning in them, and are to a point mission critical, for them at least. And FWIW, I'm merely a non-jerk and non-God-complex sysadmin that tries to answer to users with proper English and not shoving their little problems down their %/%/.

And yes, SVN might sometimes cause problems, especially when linked to these buzzwords: SASL, LDAP, NFS, VM and 1TB worth of data.

Comment: Re:Not better than the others (Score 1) 705

by cpct0 (#35283692) Attached to: Why You Shouldn't Reboot Unix Servers

And I agree with you totally it should not require a reboot, reboots should not happen.

Like in Windows ...

But in real life, they do. And sometimes, once it's determined what the cause might be, it's much easier to do a "shutdown -r 0", wait for 30 seconds for the server to stop, wait for 2 minutes for the server to come back up, look at the log, see everything is peachy, and THEN solving whatever went wrong than taking 2 hours of my life with users poking me every 30 seconds because the server is down.

Example that just happened today: a NFS server was having problems with some actions... not all, but some very rare admin actions. We restarted the server because it was hung, with stale NFS mounts galore, and application hung because it was unresponsive.
Rebooting the whole system meant all processes at least tried to stop, and then they restarted correctly. After further investigation with whatever was causing problems, we understood one of our new servers needed nolock in clients due to a software glitch. We remounted with additional options, and it kept running along from that point on. Next step is to do the right thing and correct the NFS software bug ... and once we'll have the latest software update, we'll allow locks yet again.

Total downtime: 5 minutes. Caveat: for 2 hours, users couldn't do a particuliar Admin command. Now: fine ... Eventually: server will be back up and ok.

Comment: Not better than the others (Score 2, Interesting) 705

by cpct0 (#35269574) Attached to: Why You Shouldn't Reboot Unix Servers

Quotes from stupid people:
You should never reboot a Mac, it's not like Windows.
You should never reboot Unix/Lunux, it's not like Windows.

Well, you shouldn't reboot Windows either. You reboot it when it goes sour. Our Windows servers seldom go sour, so we don't reboot them. Same for Mac or *nix.

Problem is when it starts to cause problems. Like our /var/spool partition deciding it has better things to do than exist... or the ever so important NFS or iSCSI mount that decides to Go West, and gives us the ??? ls we all dread ... with umounting impossible, so remounting impossible, and all these stale files and stuff. You either tweak these things for hours cleaning up all processes, or you reboot.

In fact, being a good sysadmin, all my servers are MEANT to be rebooted if something goes sour. One SVN project goes sour? check if it's not the repository itself that got problems, or if the system needs to save something to safely exist ... and if not, reboot the server. Everything magically restarts itself, does its little sanity check, and a quick look at a remote syslog to make certain everything is all right. 2 minutes lost for everyone, not 3 hours of trying to clean up mess left by some stray process somewhere or trying to kill the rogue 100 compression and rsync jobs that got started eating up all RAM, CPU and network.

Since all our servers are single processes and are either VMs or single machines, it's a breeze to do this. iSCSI will diligently wait before the machine is back up before trying to reconnect. NFS will keep its locked files up, and will reconnect to them. No, seriously, everything simply reconnects!

Of course, the idea is to minimize these occurences, so we learn from it, and we try to repair what could've caused this problem in the first place. And there's a place to do this in a server crash postmortem. But no need to make users wait while we try to figure out wth.

Noise proves nothing. Often a hen who has merely laid an egg cackles as if she laid an asteroid. -- Mark Twain

Working...