I always wondered why tech offices were located in the centre of some crappy city or soulless business park (eg Winnersh in Reading, sigh).
If I had a big company to set up somewhere, it'd be in an area usually frequented by tourists - there are enough people wanting to move from their shitty rat race commute that they would want to relocate to a nice area. And you'd have the side benefit of having a trapped workforce who would never want to relocate back to their grimy city commute days.
Even Paul says its not too good (without saying "its too underpowered"):
Whether the Stream's Celeron process, 2 GB of RAM and 32 GB of eMMC storage will stand the test of time will of course require some, well, time. But I can offer a few quick observations.
First, this configure seems perfectly capable of running Windows 8.1 (and thus Windows 10 as well) and doing well for the types of casual computing tasks one should expect of such a machine. You can run Word and Office 2013. IE. Facebook. That kind of thing. My bloated Chrome configuration, with multiple add-ons, quickly overwhelmed available memory, and while it does run fine, you won't want to run Chrome alongside any other heavy hitters.
so its not really enough to browse the web with the addons one expects nowadays (and I assume heavy javascript web pages) and do anything else, and he goes one to say you have 10gb storage free. You'll have to carefully manage that once you store a load of music or movies on it.
no, true... but then Google doesn't expect you to pay regularly to continue to keep accessing your files (first year free).
I would say that a lot of Google services have not been closed but morphed into a different product - Wave was the start for functionality now in Google Docs for example.
Na, there's always been a few open source projects in MS, I think they're semi-official projects that someone started and released in a way to sell more of the tools.
Wix was the first, it is an xml-baased editor that creates installer packages.
Then they did ASP.NET MVC Razor 5 (or whatever its called) which is basically a web-site project template with some 'magic' framework code. I think this ships with Visual Studio now.
And now they have OneGet... fair enough. I doubt anyone at Microsoft will be too unhappy its open source, its not exactly critical to the base platform, but it keeps the consumers of Windows happy - and they have already bought Windows so the Microsoft suits are happy too.
really? My name is Jonathan Smith... go ahead punk, find me.
You need a bit more information that that, usually a partial address to narrow things down, but other item such as phone number will readily identify you (but if you have the phone number, you're pretty much uniquely identified already, who needs name)
possibly group bias - same reason women get attacked on twitter.
If I know there are people out there who will attack women for no reason, then I can happily attack women knowing that I will get a ton of others joining in. It validates my sense of importance within a group and gives me the sense of safety from my actions because they are shared by a large number of others.
This self-fulfilment is why I think it happens, and why the bully only attacks the weak - they know they will get other bullies joining in. If they attacked someone popular, they know they wouldn't get the same level of support, so they don't.
I'll leave it to you to decide if politicians are of the same maturity level as school bullies:-)
Binary files are better is many, many respects - smaller, and more efficient to parse generally..
However, when the file is text then the benefits of binary are completely lost. If you're writing only text out then there is no benefit to binary. If you're writing out a lot of integers or serialised objects then, sure, binary is better. But text output in binary is exactly as efficient as text output to a text file.
So the question is - what kind of gubbins is being written to these logs and why aren't they just text messages anyway?
I know Windows event log writes binary as it likes to do lookups of the text so your log line will be a set of values that are placed into placeholders in a text-based message file. This keeps the log size down, but you need to have the dll that contains the message files present to read them. if you've ever been sent an event log from a windows box where the message dll is missing you'll know what I mean - you just get the error codes and the placeholder values. Not too useful.
So for logging, a text log is vastly superior because of of its reliability. A corrupt text file can often still be read. A binary file, not so much so. So you are trading off practically nothing of value for significant risk in being able to read the log, and the benefit is a little, tiny, bit of efficiency in writing it. On today's systems, writing a text file is hardly a problem.
I think you need to read up on what the system does instead of blindly following it.
PHP used to use the crypt() function, which would generate a DES or MD5 hash. In PHP 5.5 they introduced the password_hash function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.
I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing. Saying "I used password_hash so I'm golden" just isn't good enough for security. This why I repeat, storing your passwords so they are not accessible is the only solution - as far as both of us know, you've been storing your passwords in something not far off plain text anyway.
To be fair you probably are using bcrypt, but don't keep thinking that's a done deal either - this guy shows you why you should not use bcrypt:-)
I know plenty. The whole point is that a hashed password is simply one that takes a little time to decrypt. For example, it was reported a year or so ago that someone had built a machine from commodity hardware that could crack a NTLM password in about 5 minutes. Now a better encryption algorithm is good, but it just kicks the can further down the road. Its not a solution, just more of a sticking plaster solution.
The best security is not to allow the attacker to get the passwords at all. How many sites have you heard of that have announced security breaches that inform all their users to immediately change all their passwords? 1? 2? Oh yeah, loads. Do you think these very large sites had security experts too?
The point of saying "keep passwords in plaintext" is not a truly valid suggestion - everyone should encrypt them, but they should not imagine for a second that it will keep the passwords secure from attackers, that job is down to architectural decisions, the idea that you store them plaintext is to make people really think about their architecture. If your passwords are plain text, you think "how else can we secure these". Leave them encrypted you think "job done, that's secure!", and then sometime later you find your password DB downloaded and is being decrypted by some arsehole off 4chan and you have to tell the media that all your users should change their passwords.
Once I worked at a financial services company and the security guy gave us a little presentation. He opened up IE (for we worked with Windows at that place, like many financial services companies) and entered the URL for the web server, then types in a string of characters into the browser address bar. And we saw it open a command prompt that had full administrative access to the webserver box. That was an exploit that Microsoft fixed... but I always wonder when another one just like that will be discovered.. for all you know, it already has been and is being used right now.
That's why you do not rely on bcrypt as the only answer to the security of your passwords (I hope you use bcrypt, last time I saw PHP it still used MD5..... crackable in minutes)
Of course, you didn't mention salting, so I hope they told you about that too. Unsalted password hashes... about as useless as chocolate teapots.
So I hope I don't use sites you coded. Its not as if 3-tier architectures are a bad thing anyway, but if your webserver has direct access to the DB, its only a matter of time before someone has all your passwords and will happily cracking them open.
lol, no. It meant that there was more of a layer between the web server and the DB server than just a php page with the DB credentials in it chmodded to 700.
Assume an attacker has taken over your web server with an exploit and now has full admin access to it. If there is no direct connectivity to the DB, all he can do to get at your DB is call the methods on the middle-tier services that the web server called. These are not "download all passwords" but small and tightly targetted services that only provide a smallpiece of the puzzle that ends up providing the end-user experience.
So, in practice there is nothing the attacker can do to really break your DB. He can attempt to hack the application server, and that is a fair point, but he still has to break it and if you're really doing security the app tier is running a different OS that the web tier, and is firewalled down so only specific ports can be accessed anyway and there are no similar services running on it (such as apache or IIS) that are the usual attack vectors. You also have more leeway in rejecting requests from the webserver that you do not have on the web side of things - whereas a webserver has to respond to anything the user sends to it, you can trust your webserver to only send you specific requests - and if your webserver sends you a mangled request you can rightly assume its been compromised and start to refuse all requests from it (this works best if you have multiple web servers). you raise a big alarm to the admin who can then investigate. Webserver hacks can often go un-noticed if the attacker is careful.
Assume the attacker is really skilled and has hacked your web server *and* your application server... he *still* cannot download all the passwords as they are store in tables that the app tier cannot read, all it can do is fire stored procedure requests at the DB which will only respond with what they were designed for. (none of which allow 'download all passwords')
So you see that while its not impossible to be secure in such an architecture, its damn right difficult for an attacker to really get at your precious data, So difficult they'll either be unable to do it (eg most kiddies with their downloaded apache or IIS hack cookbooks) or will find it so difficult they'll get caught, or they'll just move on to another target.
We used to have a linux web tiier, and a windows middle tier. We encrypted the DB credentials in a web.config and ran the services, each on a different user. The DB sprocs also were allowed access to only those services that required it. I would never encrypt the web tier access to the DB, because I would never allow it. An attacker could take that credential file offline and hack it at his leisure. Its best if he is not given the chance to read it at all. But worse, if he can logon as that user then he can access the DB without even knowing the password. Storing it on the easily-hacked box is the flaw here. Make it hard for them, and assume your webserver is already hacked when you code your site.
As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access. ensure they work in pairs perhaps and maybe (and this is radical for a lot of companies), treat them well so they don't become disgruntled!
bullshit. They bought it from the government, whose representation of its citizens occurs roughly every 5 years for a fortnight. Apart from that time, they do what they like. And even in that fortnight they just tell you what you wanted to hear anyway.
If you treat each word as a symbol, rather than each letter, then you find the average vocabulary is about 10000 symbols and you have just generated a 4-character password (admittedly in base-10000 rather than base-26) but you'll find its still easily crackable, especially if the hacker uses pre-generated rainbow tables.
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours. For reference, 16 random characters would take 2.5 billion years (ie 64^16 = 8*10^28, which is 8*10^16 trillion seconds, or 2512 million years). Ok probability says your chances are on average half that.. only 1.25 million years.
The best password is a random one, use a tool to generate and store them and let it type them into the password field. If you must use a xkcd style password, at least stick a digit between each word.
Its not about entering passwords on the web login page, but securing the back-end system so that the password database cannot be stolen.
I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password. (incidentally, the developers didn't have access to production servers either)
So sites like ebay et al have direct DB connectivity to their DBs, so if any hacker exploits some zero day that gives them access to the OS, they can simple "select * from user" and download every password, hashed or not, and crack them at their leisure.
Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected in other ways so the hacker cannot access them in any circumstance.
However, what I do find strange is that web devs do not know this, I wrote the above for an ArsTechnica comment and the "security editor" promoted a criticism of it where the concept of a 3-tier architecture was "too expensive" an d"inefficient", suggesting that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.
and CodePlex, which although hosted my Microsoft does a better UI job of the overall thing than Google Code (which has dropped support for binary releases, telling you to use dropbox or something instead), and has a pretty poor tracker.
I found github to be a bit 'meh' too in terms of usability, though still better than google code.
I'm not sure what the best one to use is, based on functionality and usability rather than something that has 'git' in the name or some vague "startup coolness". If anyone can enlighten us, I'd appreciate it.
I thought they'd turned off all extraneous 'eye candy' to get a slim, lean, 'clean', look that was very efficient... and so I fully expect them to start making some tiles translucent in the next release, and then with shiny graphical highlights too.
Maybe one day they'll make buttons that look like buttons so you know where to click!
You have the same log history in git as you do in Svn - a linear chain of commits. What you describe as a tree is due to the branching and merging. SVN has the same thing, you branch just as much as you do with git, the difference is how the 2 store this information internally.
eg where I work, we use feature branches for independant development. Then the final fixes get merged to the product release branches and trunk. Not too dissimilar from how you tend to use git.
I worked at a place that used git (alas, not me, I was in the Windows team and had to use TFS:( ) and too many people used ot have to call the git guru over because they would munge up their repos. I don't know how they did it, but the fact that they did it too often for my tastes suggests git is a tool that is only for advanced, or experienced users only. Unfortunately that means nowhere near enterprise development.
Today, I'd never suggest git, I'd go with Fossil if I needed a DVCS.
the trouble with DVCSs is there is no repository to backup. Everyone has their copies and a vape in one can (and will) be propagated to the others. Restore your repo from backups and watch as someone then commits the vape when they push their changes to you - the system doesn't know that it shouldn't take that commit.
Its not like a centralized system where you can have proper backups.
you can have a pop at SVN for many things (hell, you can have a pop at anything for the same reasons) but seriously, you're trying to use those arguments?
SVN's security is like all the others, except for servers like VIsualSVN that implement active directory auth. Its not unstable at all, more people complain about it not being more bleeding edge, but of course its job is to be stable. They updated to serf, 3 years ago? and there were issues in the betas. Whoop, what did you expect.
And the 'philosophy' that you cannot ever obliterate history is a good one, one that all other SCMs should follow. If you commit something you shouldn't, it should be a serious thing to remove that history - otherwise everyone will screw your SCM up, and your SCM is the one thing you do not ever want screwed up.
Exactly. I don't know why there's such nerdage against SVN except that git is hard, so therefore its better somehow. Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.
If something is working, there's no point in trying to break it. And if you were to go break it, you'd go with Fossil anyway, git done right.
of course an even more obvious solution is to open your own ice franchise at Burning Man, there's obviously the demand if queue's are an hour long, and £3 for a bag of water.... and he can implement his idea, make a fortune *and* post smugly about how great he is for thinking it up!
but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?
What it will do is divide the Linux distros into systemd and dependencies, and those without (or with something better). If projects like Gnome become more tied into systemd, will this mean they won't work on non-systemd distros?
Production is essential to the mix here, we tried the concept of simply driving an economy by selling each other non-produced things (typically services, like mortgages and loans) and you saw what happened there around 2007/2008.
An economy cannot be spun out of thin air, we need to sell stuff to each other - sure, but we need to sell stuff we need to buy and make sure its regulated so we don't go into another spiral of 'profits' generated out of our imaginations. After all, my house is worth a million dollars, so I'm incredibly rich.
There is an issue with investment - as you noted. As the rate of return drops due to too much investment money chasing yields, investors demand more interest-bearing investments, which is why housing (as 1 example) has gotten out of control. Instead of investing in productivity, they are simply inflating a bubble (again). This can't be healthy for an economy.
Slashdot Mirror
I always wondered why tech offices were located in the centre of some crappy city or soulless business park (eg Winnersh in Reading, sigh).
If I had a big company to set up somewhere, it'd be in an area usually frequented by tourists - there are enough people wanting to move from their shitty rat race commute that they would want to relocate to a nice area. And you'd have the side benefit of having a trapped workforce who would never want to relocate back to their grimy city commute days.
Even Paul says its not too good (without saying "its too underpowered"):
Whether the Stream's Celeron process, 2 GB of RAM and 32 GB of eMMC storage will stand the test of time will of course require some, well, time. But I can offer a few quick observations.
First, this configure seems perfectly capable of running Windows 8.1 (and thus Windows 10 as well) and doing well for the types of casual computing tasks one should expect of such a machine. You can run Word and Office 2013. IE. Facebook. That kind of thing. My bloated Chrome configuration, with multiple add-ons, quickly overwhelmed available memory, and while it does run fine, you won't want to run Chrome alongside any other heavy hitters.
so its not really enough to browse the web with the addons one expects nowadays (and I assume heavy javascript web pages) and do anything else, and he goes one to say you have 10gb storage free. You'll have to carefully manage that once you store a load of music or movies on it.
no, true... but then Google doesn't expect you to pay regularly to continue to keep accessing your files (first year free).
I would say that a lot of Google services have not been closed but morphed into a different product - Wave was the start for functionality now in Google Docs for example.
That would be here
Na, there's always been a few open source projects in MS, I think they're semi-official projects that someone started and released in a way to sell more of the tools.
Wix was the first, it is an xml-baased editor that creates installer packages.
Then they did ASP.NET MVC Razor 5 (or whatever its called) which is basically a web-site project template with some 'magic' framework code. I think this ships with Visual Studio now.
And now they have OneGet... fair enough. I doubt anyone at Microsoft will be too unhappy its open source, its not exactly critical to the base platform, but it keeps the consumers of Windows happy - and they have already bought Windows so the Microsoft suits are happy too.
really? My name is Jonathan Smith... go ahead punk, find me.
You need a bit more information that that, usually a partial address to narrow things down, but other item such as phone number will readily identify you (but if you have the phone number, you're pretty much uniquely identified already, who needs name)
possibly group bias - same reason women get attacked on twitter.
If I know there are people out there who will attack women for no reason, then I can happily attack women knowing that I will get a ton of others joining in. It validates my sense of importance within a group and gives me the sense of safety from my actions because they are shared by a large number of others.
This self-fulfilment is why I think it happens, and why the bully only attacks the weak - they know they will get other bullies joining in. If they attacked someone popular, they know they wouldn't get the same level of support, so they don't.
I'll leave it to you to decide if politicians are of the same maturity level as school bullies :-)
I guess this year won't be the year of the linux desktop.
but you'll be able to tell much faster now.
Binary files are better is many, many respects - smaller, and more efficient to parse generally..
However, when the file is text then the benefits of binary are completely lost. If you're writing only text out then there is no benefit to binary. If you're writing out a lot of integers or serialised objects then, sure, binary is better. But text output in binary is exactly as efficient as text output to a text file.
So the question is - what kind of gubbins is being written to these logs and why aren't they just text messages anyway?
I know Windows event log writes binary as it likes to do lookups of the text so your log line will be a set of values that are placed into placeholders in a text-based message file. This keeps the log size down, but you need to have the dll that contains the message files present to read them. if you've ever been sent an event log from a windows box where the message dll is missing you'll know what I mean - you just get the error codes and the placeholder values. Not too useful.
So for logging, a text log is vastly superior because of of its reliability. A corrupt text file can often still be read. A binary file, not so much so. So you are trading off practically nothing of value for significant risk in being able to read the log, and the benefit is a little, tiny, bit of efficiency in writing it. On today's systems, writing a text file is hardly a problem.
I think you need to read up on what the system does instead of blindly following it.
PHP used to use the crypt() function, which would generate a DES or MD5 hash. In PHP 5.5 they introduced the password_hash function to replace this, but it has a mode that generates backward-compatible crypt() style hashes, so if you pass the wrong arguments to it, you will be generating md5 (or worse) hashes.
I don't mean to sound rude (even though you did say you thought I knew "fuck all") but you really need to understand what you're doing. Saying "I used password_hash so I'm golden" just isn't good enough for security. This why I repeat, storing your passwords so they are not accessible is the only solution - as far as both of us know, you've been storing your passwords in something not far off plain text anyway.
To be fair you probably are using bcrypt, but don't keep thinking that's a done deal either - this guy shows you why you should not use bcrypt :-)
I know plenty. The whole point is that a hashed password is simply one that takes a little time to decrypt. For example, it was reported a year or so ago that someone had built a machine from commodity hardware that could crack a NTLM password in about 5 minutes. Now a better encryption algorithm is good, but it just kicks the can further down the road. Its not a solution, just more of a sticking plaster solution.
The best security is not to allow the attacker to get the passwords at all. How many sites have you heard of that have announced security breaches that inform all their users to immediately change all their passwords? 1? 2? Oh yeah, loads. Do you think these very large sites had security experts too?
The point of saying "keep passwords in plaintext" is not a truly valid suggestion - everyone should encrypt them, but they should not imagine for a second that it will keep the passwords secure from attackers, that job is down to architectural decisions, the idea that you store them plaintext is to make people really think about their architecture. If your passwords are plain text, you think "how else can we secure these". Leave them encrypted you think "job done, that's secure!", and then sometime later you find your password DB downloaded and is being decrypted by some arsehole off 4chan and you have to tell the media that all your users should change their passwords.
Once I worked at a financial services company and the security guy gave us a little presentation. He opened up IE (for we worked with Windows at that place, like many financial services companies) and entered the URL for the web server, then types in a string of characters into the browser address bar. And we saw it open a command prompt that had full administrative access to the webserver box. That was an exploit that Microsoft fixed... but I always wonder when another one just like that will be discovered.. for all you know, it already has been and is being used right now.
That's why you do not rely on bcrypt as the only answer to the security of your passwords (I hope you use bcrypt, last time I saw PHP it still used MD5..... crackable in minutes)
Of course, you didn't mention salting, so I hope they told you about that too. Unsalted password hashes... about as useless as chocolate teapots.
So I hope I don't use sites you coded. Its not as if 3-tier architectures are a bad thing anyway, but if your webserver has direct access to the DB, its only a matter of time before someone has all your passwords and will happily cracking them open.
lol, no. It meant that there was more of a layer between the web server and the DB server than just a php page with the DB credentials in it chmodded to 700.
Assume an attacker has taken over your web server with an exploit and now has full admin access to it. If there is no direct connectivity to the DB, all he can do to get at your DB is call the methods on the middle-tier services that the web server called. These are not "download all passwords" but small and tightly targetted services that only provide a smallpiece of the puzzle that ends up providing the end-user experience.
So, in practice there is nothing the attacker can do to really break your DB. He can attempt to hack the application server, and that is a fair point, but he still has to break it and if you're really doing security the app tier is running a different OS that the web tier, and is firewalled down so only specific ports can be accessed anyway and there are no similar services running on it (such as apache or IIS) that are the usual attack vectors. You also have more leeway in rejecting requests from the webserver that you do not have on the web side of things - whereas a webserver has to respond to anything the user sends to it, you can trust your webserver to only send you specific requests - and if your webserver sends you a mangled request you can rightly assume its been compromised and start to refuse all requests from it (this works best if you have multiple web servers). you raise a big alarm to the admin who can then investigate. Webserver hacks can often go un-noticed if the attacker is careful.
Assume the attacker is really skilled and has hacked your web server *and* your application server... he *still* cannot download all the passwords as they are store in tables that the app tier cannot read, all it can do is fire stored procedure requests at the DB which will only respond with what they were designed for. (none of which allow 'download all passwords')
So you see that while its not impossible to be secure in such an architecture, its damn right difficult for an attacker to really get at your precious data, So difficult they'll either be unable to do it (eg most kiddies with their downloaded apache or IIS hack cookbooks) or will find it so difficult they'll get caught, or they'll just move on to another target.
We used to have a linux web tiier, and a windows middle tier. We encrypted the DB credentials in a web.config and ran the services, each on a different user. The DB sprocs also were allowed access to only those services that required it. I would never encrypt the web tier access to the DB, because I would never allow it. An attacker could take that credential file offline and hack it at his leisure. Its best if he is not given the chance to read it at all. But worse, if he can logon as that user then he can access the DB without even knowing the password. Storing it on the easily-hacked box is the flaw here. Make it hard for them, and assume your webserver is already hacked when you code your site.
As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access. ensure they work in pairs perhaps and maybe (and this is radical for a lot of companies), treat them well so they don't become disgruntled!
bullshit. They bought it from the government, whose representation of its citizens occurs roughly every 5 years for a fortnight. Apart from that time, they do what they like. And even in that fortnight they just tell you what you wanted to hear anyway.
sure, but covertly serving gays have been there since.. well, shortly after the Greek empire ended.
Because its wrong.
If you treat each word as a symbol, rather than each letter, then you find the average vocabulary is about 10000 symbols and you have just generated a 4-character password (admittedly in base-10000 rather than base-26) but you'll find its still easily crackable, especially if the hacker uses pre-generated rainbow tables.
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours. For reference, 16 random characters would take 2.5 billion years (ie 64^16 = 8*10^28, which is 8*10^16 trillion seconds, or 2512 million years). Ok probability says your chances are on average half that.. only 1.25 million years.
The best password is a random one, use a tool to generate and store them and let it type them into the password field. If you must use a xkcd style password, at least stick a digit between each word.
Its not about entering passwords on the web login page, but securing the back-end system so that the password database cannot be stolen.
I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password. (incidentally, the developers didn't have access to production servers either)
So sites like ebay et al have direct DB connectivity to their DBs, so if any hacker exploits some zero day that gives them access to the OS, they can simple "select * from user" and download every password, hashed or not, and crack them at their leisure.
Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected in other ways so the hacker cannot access them in any circumstance.
However, what I do find strange is that web devs do not know this, I wrote the above for an ArsTechnica comment and the "security editor" promoted a criticism of it where the concept of a 3-tier architecture was "too expensive" an d"inefficient", suggesting that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.
and CodePlex, which although hosted my Microsoft does a better UI job of the overall thing than Google Code (which has dropped support for binary releases, telling you to use dropbox or something instead), and has a pretty poor tracker.
I found github to be a bit 'meh' too in terms of usability, though still better than google code.
I'm not sure what the best one to use is, based on functionality and usability rather than something that has 'git' in the name or some vague "startup coolness". If anyone can enlighten us, I'd appreciate it.
I thought they'd turned off all extraneous 'eye candy' to get a slim, lean, 'clean', look that was very efficient... and so I fully expect them to start making some tiles translucent in the next release, and then with shiny graphical highlights too.
Maybe one day they'll make buttons that look like buttons so you know where to click!
You have the same log history in git as you do in Svn - a linear chain of commits. What you describe as a tree is due to the branching and merging. SVN has the same thing, you branch just as much as you do with git, the difference is how the 2 store this information internally.
eg where I work, we use feature branches for independant development. Then the final fixes get merged to the product release branches and trunk. Not too dissimilar from how you tend to use git.
I worked at a place that used git (alas, not me, I was in the Windows team and had to use TFS :( ) and too many people used ot have to call the git guru over because they would munge up their repos. I don't know how they did it, but the fact that they did it too often for my tastes suggests git is a tool that is only for advanced, or experienced users only. Unfortunately that means nowhere near enterprise development.
Today, I'd never suggest git, I'd go with Fossil if I needed a DVCS.
the trouble with DVCSs is there is no repository to backup. Everyone has their copies and a vape in one can (and will) be propagated to the others. Restore your repo from backups and watch as someone then commits the vape when they push their changes to you - the system doesn't know that it shouldn't take that commit.
Its not like a centralized system where you can have proper backups.
you can have a pop at SVN for many things (hell, you can have a pop at anything for the same reasons) but seriously, you're trying to use those arguments?
SVN's security is like all the others, except for servers like VIsualSVN that implement active directory auth. Its not unstable at all, more people complain about it not being more bleeding edge, but of course its job is to be stable. They updated to serf, 3 years ago? and there were issues in the betas. Whoop, what did you expect.
And the 'philosophy' that you cannot ever obliterate history is a good one, one that all other SCMs should follow. If you commit something you shouldn't, it should be a serious thing to remove that history - otherwise everyone will screw your SCM up, and your SCM is the one thing you do not ever want screwed up.
Exactly. I don't know why there's such nerdage against SVN except that git is hard, so therefore its better somehow. Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.
If something is working, there's no point in trying to break it. And if you were to go break it, you'd go with Fossil anyway, git done right.
of course an even more obvious solution is to open your own ice franchise at Burning Man, there's obviously the demand if queue's are an hour long, and £3 for a bag of water.... and he can implement his idea, make a fortune *and* post smugly about how great he is for thinking it up!
but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?
What it will do is divide the Linux distros into systemd and dependencies, and those without (or with something better). If projects like Gnome become more tied into systemd, will this mean they won't work on non-systemd distros?
Production is essential to the mix here, we tried the concept of simply driving an economy by selling each other non-produced things (typically services, like mortgages and loans) and you saw what happened there around 2007/2008.
An economy cannot be spun out of thin air, we need to sell stuff to each other - sure, but we need to sell stuff we need to buy and make sure its regulated so we don't go into another spiral of 'profits' generated out of our imaginations. After all, my house is worth a million dollars, so I'm incredibly rich.
There is an issue with investment - as you noted. As the rate of return drops due to too much investment money chasing yields, investors demand more interest-bearing investments, which is why housing (as 1 example) has gotten out of control. Instead of investing in productivity, they are simply inflating a bubble (again). This can't be healthy for an economy.