I mean, "I can't imagine how research could dispel the risk of unanticipated consequences from this type of environmental manipulation."
That is, research itself I would not ban, unless it gets to the point of large-scale testing in the open environment.
Even if large-scale testing in the open environment is proven to be safe via sufficiently demonstrated research? Sorry man, the people behind the ban jumped the gun way too early.
Such a person couldn't be considered a "software architect" then. The very definition of a "software architect" is one who makes simple things way the fuck too complex, and complex things damn near impossible.
References for that definition please.
What you're looking for is merely a team of software developers who see "software architecture" for the bullshit that it is. The GCC, LLVM, FreeBSD, OpenBSD and Linux communities, for instance, do a fantastic job of keeping "software architecture" in check, while still developing amazingly complex, practical and very high-quality software.
So you take a few collaborative examples and that's your proof that software architecture is hogwash? GCC has a very simple architecture, and so does the Linux Kernel (whose sole architect has been Torvalds.)
Secondly, they rely on a collaborative model with no hard deadlines of financial impact. The whole thing is uncomparable to situations where one needs a software architect. I mean, apples and oranges man.
Seriously, you don't know what you are talking about.
"Software architects" are by far one of the worst things that can happen to a company that develops software products.
Instead of developing useful software products that improve the efficiency of their customers, such companies spins their wheels developing "frameworks" that are rife with "patterns", "inversion of control", "service-oriented architectures", "clouds", and all sorts of other nonsense. Yet somehow these frameworks end up being hugely complex piles of shit. The original software products end up being ignored or remain undeveloped, since so many resources went into developing these cock-awful frameworks.
You might have had some sad encounters with architect astronauts. But that does not put a shed of truth in that emotional generalizing barrage you just made. The fact that a lot of people actually voted it insightful sheds a sad light on how little/.ers actually understand what software architecture entails.
Having a single technical lead across a company as diverse as Microsoft possibly is a bad thing -- should SQL Server, Word, XBox Live, and Phone 7 all be managed by the same technical lead? Is that one person really going to have a deep understanding of all the technical, business, and user issues across all the products, or are they inevitably going to skew towards their favourite area, or not have enough time to devote to all the areas to be both effective and timely? I suspect Ozzie just found there wasn't enough time in the day anymore. For Gates, being across everything probably worked better -- the whole company was his baby; for Ozzie, coming in from the outside and trying to be across everything might have been harder.
Obviously not, that's what delegation was invented for. At the same time, I think you do need someone - very probably just one person - at the top leading the software development.
I don't mean for one minute that they should be cutting code, but they should certainly be looking at the various products and asking "Are we doing this the best way possible? Are there obvious things wrong with that product that we should be fixing? How can we make it better?".
In a diverse company like MS, that cannot be a single chief technical architect. A CTO would be more precise.
Not sure whether I'm in the green community, but I do think NOT damaging the environment is better than going ahead and damaging it with impunity in the hopes of patching it back up with some unproven scheme.
And the scheme will remain unproven because the ban targets research into that scheme. I could understand limiting deployment without sufficient safeguards, but limiting research? Putting a black eye on this specific research because of the potential side effect of its deployment (not of research itself) is based on a claim that is itself as unproven as the scheme you think you are debating.
Its usually a good indication that they are ignored or virtually ignored. Perhaps they are read but they would be discarded as quickly as they are read, without any further discussion, comment or "nod of the head" as W B Yeats would say..
Uhmmmm, not necessarily. For example, I follow certain lead developers, tech entrepreneurs, scientists and ex-coworkers on Twitter. Typically they post some very interesting tweets that I simply bookmark or forward to friends and present/former colleagues. I rarely re-tweet. Sometimes I reply back with a tweet, but never engage in a twitter tech-related conversation.
Maybe my experience with Twitter might not be the norm, but I highly doubt that it is that rare either. Despite of what some people like to think, there are brilliant people on twitter producing information, much of which ends up being consumed outside of the twitter system of things. And that's what makes it very hard to gauge a tweet's lack of relevance. The lack of tracking such consumption constitutes a lack of evidence of something being ignored.
Trying to prove, infer or claim with some accuracy that something in Twitter is being ignored because there is no visible proof that it is not is akin to proving a negative. In other words, don't do it, for it is not logical.
> On those systems you refer to, where they facing the external world, or where they inside an intranet?
Outside world. If you don't listen on ports anyway, where is the use in firewalling them? (Yes, there can be issues, especially with dDoS. But then, if your firewall has a remote exploit, that is additional risk, as well)
I see your point (wrt to exploits on the firewall). Don't get me wrong, I know there are outside-facing boxes that are not behind firewalls (a managed box on a provider for example), and indeed if a box is not listening to ports, then it is typically not open to exploits.
Having said that, I (and this is just personal preference) prefer security in depth - double firewalled with actual firewalls around a subnet and software firewalls on the boxes. The advantage of this is (IMO) that the firewalls can represent corporate-wide policies, which are then further refined/restricted by the boxes (the later being dependent on the actual functions carried by each box.)
A glitch/exploit on a hardware firewall (or a configuration or patch mistake) is an (probabilistic) event that is independent on a glitch/exploit (or firewall config or patch on the box.) The occurrence of one gets ameliorated by the not-occurrence (sp?) on the other. Furthermore (and because these are independent events) the probability of both glitches/exploits to occur is less (sometimes substantially less) than the occurrence of a glitch/exploit on either the firewall or box.
The approach of double-firewalling (or n-firewalling) is safer by a factor of 2 (or n) than the approach of not having a firewall. The cons of this is the added complexity in configuration, management, patching and all that necessary crap.
The approach of not having a firewall is invariably less safe (also by a factor of 2... or n) with the pro of being simpler to configure and audit.
So, just like anything in software and systems, it is a matter of trade-offs, availability of resources and a clear understanding of the specific security requirements of an organization (is it sufficiently secure vs is is realistically manageable.)
> We have to work with them.
You do, I don't.
Lucky you:)
When I was approached about being the only one with Linux on the desktop and integrating into the Windows infrastructure, I told them that I would quit if I had to work on, or with, Windows. Problem solved.
This may sound like I am wagging my e-dick, but I am truly trying to make my POV clearer. Thankfully, I am in a position where I can truly not care about Windows other than the odd family members' plea for help.
Interesting approach. To each its own. For me, each OS is simply a tool, each with their weaknesses and strengths. For me and my purposes alone, I'd chose Linux. But when it comes to a customer or an employer, I'd recommend either one depending on the specific context according to an analysis trade-off. I wouldn't do my job (which is what I'm getting paid for) as an engineer otherwise.
> Every single production UNIX/Linux box I've encountered has sit behind a NAT/firewall. Machines that are not unfiltered (be it *NIX or Windows) typically sit within an intranet already enclosed by NATs/firewalls.
I know about a load of *NIX machines that are not behind any firewall whatsoever. Some run iptables locally, most don't.
And yes, by secure, I mean "keep others out of the machine". I don't care too much about local access control as different services run on different VMs anyway and the desktop machines only have a handful of users at max. And once there is reason to suspect anything has been compromised it's reinstalled, anyway. I am not sure how SELinux etc don't count as they are clearly something that exists within the *NIX context. That's like claiming the Windows family does not have have anything to write documents with as Office is not on the CD.
On those systems you refer to, where they facing the external world, or where they inside an intranet?
So, to be clear "in the context of direct & indirect remote exploits, *NIX is more secure than Windows". Also "in the context of direct & indirect local exploits, *NIX is more secure than Windows".
Ok, I see now what your argument is, and I agree with you. I'll argue that those exploits are primarily the result of the DAC implementation as done by the NT architecture (and the OS families that follow it). That on itself is a severe weakness of NT, and I wouldn't argue against that.
I can't say too much about MAC on Windows as I don't really care or know much about it. I seem to remember several exploits bypassing most security measures, though. And less of those with SELinux.
Meh, I do have to care about MAC/RBAC on Windows and Linux for a variety of reasons - defense industry, plus I've worked in environments that require much more than what DAC provides (insurance industry, HIPAA compliance, attribute-based access control of private records.)
For some things, a NT architecture provides a nicer, easier to configure turn-key MAC platform than a SELinux based one. And on a business environment, many (not all) exploits would be solved simply by adopting a corporate wide MAC strategy. The reality is that NT systems won't go away anytime soon no matter how we try using modern Linux (or other alternative) distros. We have to work with them.
So the secure thing to do is learn how to secure them and how to manage security using a centralized (but easy to distribute), corporate-wide MAC policy. Ignoring that reality is not (and cannot be) part of a responsible security engineering process.
For the security problems faced by typical users on a DAC-by-default environment, that's a related, yet different problem altogether that requires different solutions (change in the NT architecture, or creation of safer, more secure alternative platforms for end-users.)
I'm not blinding praising one over the other, nor I'm a Windows fan. But you gotta give engineering credit where it is due, even if it is to an aspect of an operating system that is not of your liking. We are all subject to subjective thinking (no pun intended), but technical discussions are worthless unless we put a modicum of effort in being objective.
You are right in a lot of what you say. Yet, none of this matters when Windows keeps on having gaping holes and *NIX seems to manage without those.
Torx is technically superior, yet you are more likely to have real-world success in the world of screwing with a Philips #2. And yes, the analogy is not 100% perfect.
Again, what type of security contexts are we talking about? For a point of view of end-user with DAC enabled, then yeah, those security holes you mentioned do matter. Those security holes exist because of a need/desire of having DAC combined with lax (or non-existing) secure systems administration.
From the point of view of isolated systems or those intended to run under a strict MAC/RBAC security model (which I think it's what the Indian Army will look for), then those security holes don't mean much since a MAC/RBAC policy becomes implemented (which can only be done with dedicated, security-aware business-specific systems administration.)
I know that many won't agree with this, and that is fine. My opinion is simply backed from working with secure deployments of both NT and Linux. I'm very biased towards *NIX systems. But even then I have to acknowledge that NT architecture with built-in integration with things like Active Directory and MAC/RBAC capabilities do make for a nice, secure and hardened package.
You can do the same with Linux, but you have to put all those integration pieces together. You have to pull a lot of things together (SELinux or AppArmor, OpenLDAP, Kerberos, etc). As of yet, there is no universally accepted procedure for going about it... and that is a security weakness.
NT architectures provide for a nice turn-key capability for implementing MAC/RBAC. I would still roll my sleeves and implement a Linux-based solution anytime (as a matter of principle and economics). However, I can't let that in good engineering consciousness stop me from admitting a NT architecture provides a superior solution (from the point of view of turn-key integration and configuration.)
Truth to be told, Linux/*NIX solutions for implementing mandatory access control models - as effective as they are - are still mired with the legacy of an obsolete DAC model. Furthermore, that obsolete model not only affects the operating system, but many of the sysadmins in charge of them (who can only think on DAC terms and who still think they can solve RBAC problems by using groups.)
So again, it is a matter of security context. Security holes encountered by a typical Windows users matter most in one security context. In others, they do not (as the security context solves them trivially.)
And when I was young, we had to walk to school, uphills both ways. We had to wrap barbed wire around our bare feet for traction on the dry ice that formed due to the cold.
In other words: I did claim that *NIX has always been perfect. I am simply saying they got their shit together a lot better, faster and more thoroughly than the Windows world.
Not true. The security model of UNIX is DAC based, reflecting a past when systems were secure by isolation. Almost no one was connected back then. The systems of the day did not reflect any of the realities Windows systems face nowadays. Not that it absolves the security blunders committed in some of the design of Windows. But the security architecture of NT (based in great part on VMS which was a lot more secure from the ground up than UNIX) is superior than what you find in a typical out-of-the-box Unix system.
Very few people armor their Linux distros to support MAC/RBAC (even when there are business reasons screaming for it). And the poor security track record of Windows systems have little to do with the NT security architecture, and more to do with the sheer number of deployments; the ambiguous role of providing "easy of use" in a time of great internet connectivity; and poor configuration practices (of which Linux folks aren't that innocent either.)
That the UNIX world got a security model faster than NT is trivially true. After all, the security model is DAC based and a reflection of the state of systems security and nature of installations 30 years ago.
Next Tuesday, MS will break the record for patches in one day. Before the recent bzip2 DoS hole, I don't even know _what_ I patched last.
Your obscurity argument would hold more water if most *NIX would not dominate the server hosting as much as it does. And those machines tend to be unfiltered while Windows machines tend to be behind NAT/a firewall.
And finally, even _if_ the obscurity argument was valid (I happen to think it's not, feel free to disagree), there is no way to make *NIX less obscure just to prove your point.
Every single production UNIX/Linux box I've encountered has sit behind a NAT/firewall. Machines that are not unfiltered (be it *NIX or Windows) typically sit within an intranet already enclosed by NATs/firewalls.
So, for all intents and purposes, as of right now, *NIX is more secure.
"Being secure" is a broad subject. For many purposes *NIX systems are more secure (from the point of view of users requiring discretionary access control). But I'll ask you, how do you implement MAC on a *NIX system (one that does not have to be retrofitted like SELinux or Linux+AppArmor)?
Explain me how.
I work with UNIX/Linux all the time and it is my preferred platform. It's been like that for the last 15 years. But even then I'll be the first to recognize that a well-configured NT system is much more secure and easier to configure (for implementing RBAC/MAC) than a Linux system. In fact, you have to get a specific distro or tooling (.ie. SELinux which is what I work with, AppArmor, Tomoyo) to get the same type of access control configuration and enforcement.
Saying "this is secure" or "that is more secure" without specifying particular contexts, that's an exercise on fanboyism.
1. Any out-of-the-box Linux system is more secure (from a DAC perspective) than an out-of-the-box system belonging to the NT architecture family (which we will simply refer to as "NT system" for the sake of brevity).
2. Any out-of-the-box NT system tends to be as configurable (and sometimes easier) to be locked with MAC/RBAC for specific business contexts than an "armored" Linux system (be it SELinux, AppArmor, Tomoyo).
3. An out-of-the-box Linux distro cannot be locked down for MAC/RBAC policies. You have to "armor" them as described in point #2.
And that's what's important to recognize, MAC/RBAC is already built-in on NT (though most people are too dumb to do so). Similary, most people don't "armor" their Linux distros because they are too dumb as well and think that DAC is all that is to be.
Security is more than just preventing trojans getting installed on your personal computers while browsing the interweebz.
So ACLs = security ?
The relative simplicity of chmod means that people actually use it.
If by people you mean regular users, then yes, DAC is sufficient. On secure installations, you need MAC, you need a lot more than chmod. A well configured NT system or a Linux distro with AppArmor or SELinux/FLASK can provide just that.
But most importantly, using 64bit int types (or bigger) rather than 32-bit ints for primary indexes?
Some languages still have no 64-bit integer type. For example, in PHP compiled for a 32-bit architecture, anything bigger than a 32-bit signed integer is a float. Or in standard C++ compiled for a 32-bit architecture, anything bigger than a 32-bit unsigned integer is a float. (C++98, the current standard, came out before long long was added to C99, so if you see long long in a C++ program, it's a compiler-specific extension.)
In cases where you don't have a 64-bit int data type (or you know that your target architecture or compiled format does not support one), simply use two 32-bit (high and low halves) as an aggregate data type, detect when an overflow of the low half is to occur and carry the overflow bit up to the high half. This is sooooo extremely easy to do in C or C++, that it is not even funny. Similarly, if a DB does not have a 64-bit type, then use the same approach just described and use a compound key (high+low) as the primary key.
How many architectures out there support 128-bit ints? And yet there is a shitload of systems that support 128-bit "big int" arithmetic in the financial world.
This is a classic solution for implementing a N*m bit counter when the max you have is a N-bit type. It is a classic, textbook CompSci 101 problem that has been successfully and efficiently solved again and again and again using virtually the exact pattern I just described above.
Having an underlying bit-type architectural constrain has never been an impediment to implement arithmetic on much, much larger bit-types. It is not insurmountable, and in fact, one could argue that it is trivial (when done right, the later which is not that difficult either.)
Sharding? Partitioning? But most importantly, using 64bit int types (or bigger) rather than 32-bit ints for primary indexes? I mean, what the hell they were using to store that data anyways? A Visicalc spreadsheet running on a TRS-80?
The power requirements are more for Windows compared to linux on the same hardware - at least on my laptop. Then again, I installed a proper linux distro, not Crapuntu.
OpenSuse is SO much more polished.
A Linux user who couldn't configure Windows XP/Vista/7 Power management features to operate with similar efficiency? Egad!!!
I think it's that Japanese have always been meticulous in everything they do. They're also very good about following rules. In many countries, particularly the US, even people who believe in recycling would likely be pissed a the prospect of having to sort their garbage so extensively.
And I can't help but wonder, why is the recycling company not doing this? Aren't these people paying taxes so that their garbage is processed properly?
We in the US have a cultural problem where people get pissed off at anything that involves them moving a finger outside of their 9-5 work schedule.
I hear ya. What you are describing is one of the many symptoms of a malady affecting the US. There is this parochial, not-in-my-backyard backward mentality where the government/something/somebody must solve all their problems so long as it does not involve them physically or financially (.ie. taxes.)
Minimal government that can solve everything, including turning lead to goal. Anything else is labeled un-American. Any attempt to change is labeled unchristian socialism (even though they are hardly christian.) Despite the fact that they want it to solve all the job-related and financial problems to the point of implementing the most entrenched of market protectionist schemes (the very definition of a socialist state which is what they blindly deride.) Everything that they do not understand (or involves them to move a bit out of their fatass comfort zones) is labeled as the very thing they actually would end up having if they had their way.
Unlike the previous generations, nowadays, this country is at its position of financial and industrial primacy not because of its people, but despite of them. Asking them the most innocuous of things, like recycling, is a bit too much an affront of their personal freedom, a most un-American thing.
it shows that current electronics recycling is not a gimmick, at least in Japan.
Not terribly sure about electronics, but with everything else you'd probably be amazed. I have 7 different garbage categories in my town. I have to put my name and location on my garbage bags. If I make a mistake in sorting the garbage, they send it back to me (it has happened more than once...). And it's not just gross sorting. With pet bottles I have to take the caps off (different category) and the labels off (different category). My yogurt containers are made from recyclable plastic covered with cardboard. I have to separate the cardboard from the plastic and put it in different containers. Etc, etc, etc...
Electronics is easy. You take it to the electronics shop and they take care of it for you. I'm not sure exactly what they do, but I'm assuming it's fairly rigorous. Japan just doesn't have any landfill space...
Where in Japan are you? Just curious.
But other than that, you are on point. I was in Yokohama during new years eve, and it is amazing the discipline involved in the proper recycling of garbage (discipline displayed by both the collectors and the general population.) I believe it is not only out of modern necessity, but that Japan has historically been a clean country, much more than any other country as testified by Eastern and Western travelers back in the day.
Has anyone with an Associates degree been hired by IBM lately in the US? Has IBM hired anyone in the US lately?
There's a whole lot of laid off IBM workers that are wondering the same thing, I'm thinking.
rd
I don't think anyone with only an associate degree gets hired by anybody nowadays (at least on IT and software). There used to be a time (15-20 years ago) where you could get a decent job developing software with only an associates degree (truth to be told, most software development only requires what a GOOD software-centric AA/AS provides). But now - and thank to the dot-com hyperbole - there is a surplus of developers with a B.S. degree expecting to make $70K right out of school (and many of them with less programming skills than a AA/AS holder had 15 years ago.)
So I don't really feel that sorry (sometimes) for 4-year CS/MIS/Eng degree holders getting the boot in favor of developers halfway across the world. Surplus programmers here and over there will tend to suck ass equally at the job they are supposed to do, but at least the ones in India and China charge for less. Whereas programmers here charge more for the same amount of programming suckage. So how can one blame companies from moving abroad? (Though I recognize that it ultimately hurts our national economy)?
We collectively do such a shitty job at software development and engineering that we have forfeit the right to complain when companies decide to offshore.
Just one quick comment - it's trivially solvable by allowing the reversal of time, and that's a valid postulate, since it's certainly easier to envision a change of direction in time (time is a dimension, after all) than it is to envision an infinitely long tape.
Yes, time is a dimension. And no, the Universe enforces one direction and one direction only to displacement on that dimension. Remember, the question was whether the Universe is equivalent (or not) to a Turing Machine (and the later, but definition, does not allow time reversal.)
So, the Universe forbids traveling back in time, and a Turing Machine is not a hypercomputing device.
If you can have your infinitely long tape, and infinite time in which to work with it, and infinite space to store it in, and an infinite power supply to run it (even the first movement of the tape would require infinite energy since it's... well... infinite), then I can certainly have my reversal of time each second.
That's begging the question. All the prerequisites you have listed do not imply the capacity of moving on the time dimension in a direction opposite to what the laws of physics enforce.
The universe is not a computer problem. The universe is also not a computational device. There's a gaping hole in your argument - the difference between == (equivalency) and === (identity), just as the picture is not the thing.
So by your own admission, the Universe is not Turing Equivalent. And in fact, it's not even comparable. So why then did you ask for a proof that the Universe is not equivalent to a Turing Machine then?
First problem ( of many ) - a representation of something is not that something. This is something that programmers forget all the time. There is no such thing as objects, methods, function calls, etc. Those are just representations. At a higher level, ordering a pizza online, and them sending you a fax of that pizza, is not going to work either. Even them sending you a complete description of the state of every single atom in a pizza is not going to work. Information, contrary to popular belief, is not equivalent to the thing being described.
In other words, even if you had a machine that was able to represent every single state of the universe, it is not equivalent to the universe. Any description of something, no matter how detailed, is not that thing, no matter how many times people chant "information theory says otherwise." It's like the pastor who preaches against same-sex marriage, saying it's unnatural and that same-sex behaviour doesn't occur in nature, but completely ignores the male dog humping his leg.
However, what you offer is not proof by contradiction. It buys into the idea that there's the possibility that the universe might be represented by a Turing machine. That's the flawed premise (but try to get people to see it when they've got their precious theories on the line).
Also, the halting problem is trivially solved by allowing the arrow of time to reverse at the end of each calculation (say once a second), so that even a near-infinite solution must, by definition, complete in 1 second of "real" time. In other words, either the Turing machine continues to exist after one second, or it disappears - stuck in an infinite time loop. This lets you know that the problem is either solvable, or not.
As for the "dude" bit, please see my profile thx bye!
There are so many things wrong and illogical with this post that don't even know where to begin. I will simply focus on the following:
Also, the halting problem is trivially solved by allowing the arrow of time to reverse at the end of each calculation (say once a second)
It's not only trivially solvable by allowing time reversal. At any point where you allow a turing machine to either a) execute an unbounded amount of steps per unit of time, and/or b) execute steps instantaneously (t=0), then it becomes solvable.
Here we are entering the realm of hypercomputability... and I knew it would not take long for a clueless poster to make a mention of it at the sight of the halting problem. You went for the bait just as I predicted it
By your own admission then, the halting problem would require a turing machine to perform an act forbidden by physics. I made a mention of the halting problem with premeditation, to see who would be the first to suggest such an inane thing (inane in the context of whether the Universe is Turing Computable.)
You asked for proof that the Universe is not Turing Computable. I gave you one by demonstrating that one problem in the universe is not turing computable. You can't equate the Universe to a Turing Machine and at the same time allow an uncomputable function be part of it.
Furthermore, you cannot balk at it and say that - and I quote you -
First problem ( of many ) - a representation of something is not that something. This is something that programmers forget all the time. There is no such thing as objects, methods, function calls, etc.
Yes, a representation of something is not that something. But the question was whether the Universe is equivalent to a Turing Machine. That is, whether the Universe is equivalent to a - guess what? - a mathematical representation of a computation device.
By asking to prove it or disprove it, you asked for a proof of the Universe being reduced to a - guess what again? - a mathematical representation of - guess what again? - another mathematical representation of a computing
Aren't the laws of physics axioms for the universe? Isn't the idea behind a grand unified theory to find one or two simple mathematical expressions (axioms) from which the rest of the universe can be derived? The universe is clearly Turing complete, so I really don't see how it wouldn't apply.
How could it be? The universe is naturally uncountable.
Slashdot Mirror
I mean, "I can't imagine how research could dispel the risk of unanticipated consequences from this type of environmental manipulation."
That is, research itself I would not ban, unless it gets to the point of large-scale testing in the open environment.
Even if large-scale testing in the open environment is proven to be safe via sufficiently demonstrated research? Sorry man, the people behind the ban jumped the gun way too early.
Such a person couldn't be considered a "software architect" then. The very definition of a "software architect" is one who makes simple things way the fuck too complex, and complex things damn near impossible.
References for that definition please.
What you're looking for is merely a team of software developers who see "software architecture" for the bullshit that it is. The GCC, LLVM, FreeBSD, OpenBSD and Linux communities, for instance, do a fantastic job of keeping "software architecture" in check, while still developing amazingly complex, practical and very high-quality software.
So you take a few collaborative examples and that's your proof that software architecture is hogwash? GCC has a very simple architecture, and so does the Linux Kernel (whose sole architect has been Torvalds.)
Secondly, they rely on a collaborative model with no hard deadlines of financial impact. The whole thing is uncomparable to situations where one needs a software architect. I mean, apples and oranges man.
Seriously, you don't know what you are talking about.
"Software architects" are by far one of the worst things that can happen to a company that develops software products.
Instead of developing useful software products that improve the efficiency of their customers, such companies spins their wheels developing "frameworks" that are rife with "patterns", "inversion of control", "service-oriented architectures", "clouds", and all sorts of other nonsense. Yet somehow these frameworks end up being hugely complex piles of shit. The original software products end up being ignored or remain undeveloped, since so many resources went into developing these cock-awful frameworks.
You might have had some sad encounters with architect astronauts. But that does not put a shed of truth in that emotional generalizing barrage you just made. The fact that a lot of people actually voted it insightful sheds a sad light on how little /.ers actually understand what software architecture entails.
Having a single technical lead across a company as diverse as Microsoft possibly is a bad thing -- should SQL Server, Word, XBox Live, and Phone 7 all be managed by the same technical lead? Is that one person really going to have a deep understanding of all the technical, business, and user issues across all the products, or are they inevitably going to skew towards their favourite area, or not have enough time to devote to all the areas to be both effective and timely? I suspect Ozzie just found there wasn't enough time in the day anymore. For Gates, being across everything probably worked better -- the whole company was his baby; for Ozzie, coming in from the outside and trying to be across everything might have been harder.
Obviously not, that's what delegation was invented for. At the same time, I think you do need someone - very probably just one person - at the top leading the software development.
I don't mean for one minute that they should be cutting code, but they should certainly be looking at the various products and asking "Are we doing this the best way possible? Are there obvious things wrong with that product that we should be fixing? How can we make it better?".
In a diverse company like MS, that cannot be a single chief technical architect. A CTO would be more precise.
You don't think a software company needs a chief software architect?
1. Not if it was Ozzie.
2. The company is split between entertainment and os/office productivity. Different animals that might require different chief architects.
Not sure whether I'm in the green community, but I do think NOT damaging the environment is better than going ahead and damaging it with impunity in the hopes of patching it back up with some unproven scheme.
And the scheme will remain unproven because the ban targets research into that scheme. I could understand limiting deployment without sufficient safeguards, but limiting research? Putting a black eye on this specific research because of the potential side effect of its deployment (not of research itself) is based on a claim that is itself as unproven as the scheme you think you are debating.
Its usually a good indication that they are ignored or virtually ignored. Perhaps they are read but they would be discarded as quickly as they are read, without any further discussion, comment or "nod of the head" as W B Yeats would say..
Uhmmmm, not necessarily. For example, I follow certain lead developers, tech entrepreneurs, scientists and ex-coworkers on Twitter. Typically they post some very interesting tweets that I simply bookmark or forward to friends and present/former colleagues. I rarely re-tweet. Sometimes I reply back with a tweet, but never engage in a twitter tech-related conversation.
Maybe my experience with Twitter might not be the norm, but I highly doubt that it is that rare either. Despite of what some people like to think, there are brilliant people on twitter producing information, much of which ends up being consumed outside of the twitter system of things. And that's what makes it very hard to gauge a tweet's lack of relevance. The lack of tracking such consumption constitutes a lack of evidence of something being ignored.
Trying to prove, infer or claim with some accuracy that something in Twitter is being ignored because there is no visible proof that it is not is akin to proving a negative. In other words, don't do it, for it is not logical.
> On those systems you refer to, where they facing the external world, or where they inside an intranet?
Outside world. If you don't listen on ports anyway, where is the use in firewalling them? (Yes, there can be issues, especially with dDoS. But then, if your firewall has a remote exploit, that is additional risk, as well)
I see your point (wrt to exploits on the firewall). Don't get me wrong, I know there are outside-facing boxes that are not behind firewalls (a managed box on a provider for example), and indeed if a box is not listening to ports, then it is typically not open to exploits.
Having said that, I (and this is just personal preference) prefer security in depth - double firewalled with actual firewalls around a subnet and software firewalls on the boxes. The advantage of this is (IMO) that the firewalls can represent corporate-wide policies, which are then further refined/restricted by the boxes (the later being dependent on the actual functions carried by each box.)
A glitch/exploit on a hardware firewall (or a configuration or patch mistake) is an (probabilistic) event that is independent on a glitch/exploit (or firewall config or patch on the box.) The occurrence of one gets ameliorated by the not-occurrence (sp?) on the other. Furthermore (and because these are independent events) the probability of both glitches/exploits to occur is less (sometimes substantially less) than the occurrence of a glitch/exploit on either the firewall or box.
The approach of double-firewalling (or n-firewalling) is safer by a factor of 2 (or n) than the approach of not having a firewall. The cons of this is the added complexity in configuration, management, patching and all that necessary crap.
The approach of not having a firewall is invariably less safe (also by a factor of 2... or n) with the pro of being simpler to configure and audit.
So, just like anything in software and systems, it is a matter of trade-offs, availability of resources and a clear understanding of the specific security requirements of an organization (is it sufficiently secure vs is is realistically manageable.)
> We have to work with them.
You do, I don't.
Lucky you:)
When I was approached about being the only one with Linux on the desktop and integrating into the Windows infrastructure, I told them that I would quit if I had to work on, or with, Windows. Problem solved.
This may sound like I am wagging my e-dick, but I am truly trying to make my POV clearer. Thankfully, I am in a position where I can truly not care about Windows other than the odd family members' plea for help.
Interesting approach. To each its own. For me, each OS is simply a tool, each with their weaknesses and strengths. For me and my purposes alone, I'd chose Linux. But when it comes to a customer or an employer, I'd recommend either one depending on the specific context according to an analysis trade-off. I wouldn't do my job (which is what I'm getting paid for) as an engineer otherwise.
> Every single production UNIX/Linux box I've encountered has sit behind a NAT/firewall. Machines that are not unfiltered (be it *NIX or Windows) typically sit within an intranet already enclosed by NATs/firewalls.
I know about a load of *NIX machines that are not behind any firewall whatsoever. Some run iptables locally, most don't.
And yes, by secure, I mean "keep others out of the machine". I don't care too much about local access control as different services run on different VMs anyway and the desktop machines only have a handful of users at max. And once there is reason to suspect anything has been compromised it's reinstalled, anyway. I am not sure how SELinux etc don't count as they are clearly something that exists within the *NIX context. That's like claiming the Windows family does not have have anything to write documents with as Office is not on the CD.
On those systems you refer to, where they facing the external world, or where they inside an intranet?
So, to be clear "in the context of direct & indirect remote exploits, *NIX is more secure than Windows". Also "in the context of direct & indirect local exploits, *NIX is more secure than Windows".
Ok, I see now what your argument is, and I agree with you. I'll argue that those exploits are primarily the result of the DAC implementation as done by the NT architecture (and the OS families that follow it). That on itself is a severe weakness of NT, and I wouldn't argue against that.
I can't say too much about MAC on Windows as I don't really care or know much about it. I seem to remember several exploits bypassing most security measures, though. And less of those with SELinux.
Meh, I do have to care about MAC/RBAC on Windows and Linux for a variety of reasons - defense industry, plus I've worked in environments that require much more than what DAC provides (insurance industry, HIPAA compliance, attribute-based access control of private records.)
For some things, a NT architecture provides a nicer, easier to configure turn-key MAC platform than a SELinux based one. And on a business environment, many (not all) exploits would be solved simply by adopting a corporate wide MAC strategy. The reality is that NT systems won't go away anytime soon no matter how we try using modern Linux (or other alternative) distros. We have to work with them.
So the secure thing to do is learn how to secure them and how to manage security using a centralized (but easy to distribute), corporate-wide MAC policy. Ignoring that reality is not (and cannot be) part of a responsible security engineering process.
For the security problems faced by typical users on a DAC-by-default environment, that's a related, yet different problem altogether that requires different solutions (change in the NT architecture, or creation of safer, more secure alternative platforms for end-users.)
I'm not blinding praising one over the other, nor I'm a Windows fan. But you gotta give engineering credit where it is due, even if it is to an aspect of an operating system that is not of your liking. We are all subject to subjective thinking (no pun intended), but technical discussions are worthless unless we put a modicum of effort in being objective.
You are right in a lot of what you say. Yet, none of this matters when Windows keeps on having gaping holes and *NIX seems to manage without those.
Torx is technically superior, yet you are more likely to have real-world success in the world of screwing with a Philips #2. And yes, the analogy is not 100% perfect.
Again, what type of security contexts are we talking about? For a point of view of end-user with DAC enabled, then yeah, those security holes you mentioned do matter. Those security holes exist because of a need/desire of having DAC combined with lax (or non-existing) secure systems administration.
From the point of view of isolated systems or those intended to run under a strict MAC/RBAC security model (which I think it's what the Indian Army will look for), then those security holes don't mean much since a MAC/RBAC policy becomes implemented (which can only be done with dedicated, security-aware business-specific systems administration.)
I know that many won't agree with this, and that is fine. My opinion is simply backed from working with secure deployments of both NT and Linux. I'm very biased towards *NIX systems. But even then I have to acknowledge that NT architecture with built-in integration with things like Active Directory and MAC/RBAC capabilities do make for a nice, secure and hardened package.
You can do the same with Linux, but you have to put all those integration pieces together. You have to pull a lot of things together (SELinux or AppArmor, OpenLDAP, Kerberos, etc). As of yet, there is no universally accepted procedure for going about it... and that is a security weakness.
NT architectures provide for a nice turn-key capability for implementing MAC/RBAC. I would still roll my sleeves and implement a Linux-based solution anytime (as a matter of principle and economics). However, I can't let that in good engineering consciousness stop me from admitting a NT architecture provides a superior solution (from the point of view of turn-key integration and configuration.)
Truth to be told, Linux/*NIX solutions for implementing mandatory access control models - as effective as they are - are still mired with the legacy of an obsolete DAC model. Furthermore, that obsolete model not only affects the operating system, but many of the sysadmins in charge of them (who can only think on DAC terms and who still think they can solve RBAC problems by using groups.)
So again, it is a matter of security context. Security holes encountered by a typical Windows users matter most in one security context. In others, they do not (as the security context solves them trivially.)
And when I was young, we had to walk to school, uphills both ways. We had to wrap barbed wire around our bare feet for traction on the dry ice that formed due to the cold.
In other words: I did claim that *NIX has always been perfect. I am simply saying they got their shit together a lot better, faster and more thoroughly than the Windows world.
Not true. The security model of UNIX is DAC based, reflecting a past when systems were secure by isolation. Almost no one was connected back then. The systems of the day did not reflect any of the realities Windows systems face nowadays. Not that it absolves the security blunders committed in some of the design of Windows. But the security architecture of NT (based in great part on VMS which was a lot more secure from the ground up than UNIX) is superior than what you find in a typical out-of-the-box Unix system.
Very few people armor their Linux distros to support MAC/RBAC (even when there are business reasons screaming for it). And the poor security track record of Windows systems have little to do with the NT security architecture, and more to do with the sheer number of deployments; the ambiguous role of providing "easy of use" in a time of great internet connectivity; and poor configuration practices (of which Linux folks aren't that innocent either.)
That the UNIX world got a security model faster than NT is trivially true. After all, the security model is DAC based and a reflection of the state of systems security and nature of installations 30 years ago.
Next Tuesday, MS will break the record for patches in one day. Before the recent bzip2 DoS hole, I don't even know _what_ I patched last.
Your obscurity argument would hold more water if most *NIX would not dominate the server hosting as much as it does. And those machines tend to be unfiltered while Windows machines tend to be behind NAT/a firewall.
And finally, even _if_ the obscurity argument was valid (I happen to think it's not, feel free to disagree), there is no way to make *NIX less obscure just to prove your point.
Every single production UNIX/Linux box I've encountered has sit behind a NAT/firewall. Machines that are not unfiltered (be it *NIX or Windows) typically sit within an intranet already enclosed by NATs/firewalls.
So, for all intents and purposes, as of right now, *NIX is more secure.
"Being secure" is a broad subject. For many purposes *NIX systems are more secure (from the point of view of users requiring discretionary access control). But I'll ask you, how do you implement MAC on a *NIX system (one that does not have to be retrofitted like SELinux or Linux+AppArmor)?
Explain me how.
I work with UNIX/Linux all the time and it is my preferred platform. It's been like that for the last 15 years. But even then I'll be the first to recognize that a well-configured NT system is much more secure and easier to configure (for implementing RBAC/MAC) than a Linux system. In fact, you have to get a specific distro or tooling (.ie. SELinux which is what I work with, AppArmor, Tomoyo) to get the same type of access control configuration and enforcement.
Saying "this is secure" or "that is more secure" without specifying particular contexts, that's an exercise on fanboyism.
1. Any out-of-the-box Linux system is more secure (from a DAC perspective) than an out-of-the-box system belonging to the NT architecture family (which we will simply refer to as "NT system" for the sake of brevity).
2. Any out-of-the-box NT system tends to be as configurable (and sometimes easier) to be locked with MAC/RBAC for specific business contexts than an "armored" Linux system (be it SELinux, AppArmor, Tomoyo).
3. An out-of-the-box Linux distro cannot be locked down for MAC/RBAC policies. You have to "armor" them as described in point #2.
And that's what's important to recognize, MAC/RBAC is already built-in on NT (though most people are too dumb to do so). Similary, most people don't "armor" their Linux distros because they are too dumb as well and think that DAC is all that is to be.
Security is more than just preventing trojans getting installed on your personal computers while browsing the interweebz.
So ACLs = security ? The relative simplicity of chmod means that people actually use it.
If by people you mean regular users, then yes, DAC is sufficient. On secure installations, you need MAC, you need a lot more than chmod. A well configured NT system or a Linux distro with AppArmor or SELinux/FLASK can provide just that.
But most importantly, using 64bit int types (or bigger) rather than 32-bit ints for primary indexes?
Some languages still have no 64-bit integer type. For example, in PHP compiled for a 32-bit architecture, anything bigger than a 32-bit signed integer is a float. Or in standard C++ compiled for a 32-bit architecture, anything bigger than a 32-bit unsigned integer is a float. (C++98, the current standard, came out before long long was added to C99, so if you see long long in a C++ program, it's a compiler-specific extension.)
In cases where you don't have a 64-bit int data type (or you know that your target architecture or compiled format does not support one), simply use two 32-bit (high and low halves) as an aggregate data type, detect when an overflow of the low half is to occur and carry the overflow bit up to the high half. This is sooooo extremely easy to do in C or C++, that it is not even funny. Similarly, if a DB does not have a 64-bit type, then use the same approach just described and use a compound key (high+low) as the primary key.
How many architectures out there support 128-bit ints? And yet there is a shitload of systems that support 128-bit "big int" arithmetic in the financial world.
This is a classic solution for implementing a N*m bit counter when the max you have is a N-bit type. It is a classic, textbook CompSci 101 problem that has been successfully and efficiently solved again and again and again using virtually the exact pattern I just described above.
Having an underlying bit-type architectural constrain has never been an impediment to implement arithmetic on much, much larger bit-types. It is not insurmountable, and in fact, one could argue that it is trivial (when done right, the later which is not that difficult either.)
Sharding? Partitioning? But most importantly, using 64bit int types (or bigger) rather than 32-bit ints for primary indexes? I mean, what the hell they were using to store that data anyways? A Visicalc spreadsheet running on a TRS-80?
The power requirements are more for Windows compared to linux on the same hardware - at least on my laptop. Then again, I installed a proper linux distro, not Crapuntu. OpenSuse is SO much more polished.
A Linux user who couldn't configure Windows XP/Vista/7 Power management features to operate with similar efficiency? Egad!!!
I think it's that Japanese have always been meticulous in everything they do. They're also very good about following rules. In many countries, particularly the US, even people who believe in recycling would likely be pissed a the prospect of having to sort their garbage so extensively.
And I can't help but wonder, why is the recycling company not doing this? Aren't these people paying taxes so that their garbage is processed properly?
We in the US have a cultural problem where people get pissed off at anything that involves them moving a finger outside of their 9-5 work schedule.
I hear ya. What you are describing is one of the many symptoms of a malady affecting the US. There is this parochial, not-in-my-backyard backward mentality where the government/something/somebody must solve all their problems so long as it does not involve them physically or financially (.ie. taxes.)
Minimal government that can solve everything, including turning lead to goal. Anything else is labeled un-American. Any attempt to change is labeled unchristian socialism (even though they are hardly christian.) Despite the fact that they want it to solve all the job-related and financial problems to the point of implementing the most entrenched of market protectionist schemes (the very definition of a socialist state which is what they blindly deride.) Everything that they do not understand (or involves them to move a bit out of their fatass comfort zones) is labeled as the very thing they actually would end up having if they had their way.
Unlike the previous generations, nowadays, this country is at its position of financial and industrial primacy not because of its people, but despite of them. Asking them the most innocuous of things, like recycling, is a bit too much an affront of their personal freedom, a most un-American thing.
it shows that current electronics recycling is not a gimmick, at least in Japan.
Not terribly sure about electronics, but with everything else you'd probably be amazed. I have 7 different garbage categories in my town. I have to put my name and location on my garbage bags. If I make a mistake in sorting the garbage, they send it back to me (it has happened more than once...). And it's not just gross sorting. With pet bottles I have to take the caps off (different category) and the labels off (different category). My yogurt containers are made from recyclable plastic covered with cardboard. I have to separate the cardboard from the plastic and put it in different containers. Etc, etc, etc...
Electronics is easy. You take it to the electronics shop and they take care of it for you. I'm not sure exactly what they do, but I'm assuming it's fairly rigorous. Japan just doesn't have any landfill space...
Where in Japan are you? Just curious.
But other than that, you are on point. I was in Yokohama during new years eve, and it is amazing the discipline involved in the proper recycling of garbage (discipline displayed by both the collectors and the general population.) I believe it is not only out of modern necessity, but that Japan has historically been a clean country, much more than any other country as testified by Eastern and Western travelers back in the day.
Has anyone with an Associates degree been hired by IBM lately in the US? Has IBM hired anyone in the US lately?
There's a whole lot of laid off IBM workers that are wondering the same thing, I'm thinking.
rd
I don't think anyone with only an associate degree gets hired by anybody nowadays (at least on IT and software). There used to be a time (15-20 years ago) where you could get a decent job developing software with only an associates degree (truth to be told, most software development only requires what a GOOD software-centric AA/AS provides). But now - and thank to the dot-com hyperbole - there is a surplus of developers with a B.S. degree expecting to make $70K right out of school (and many of them with less programming skills than a AA/AS holder had 15 years ago.)
So I don't really feel that sorry (sometimes) for 4-year CS/MIS/Eng degree holders getting the boot in favor of developers halfway across the world. Surplus programmers here and over there will tend to suck ass equally at the job they are supposed to do, but at least the ones in India and China charge for less. Whereas programmers here charge more for the same amount of programming suckage. So how can one blame companies from moving abroad? (Though I recognize that it ultimately hurts our national economy)?
We collectively do such a shitty job at software development and engineering that we have forfeit the right to complain when companies decide to offshore.
Just one quick comment - it's trivially solvable by allowing the reversal of time, and that's a valid postulate, since it's certainly easier to envision a change of direction in time (time is a dimension, after all) than it is to envision an infinitely long tape.
Yes, time is a dimension. And no, the Universe enforces one direction and one direction only to displacement on that dimension. Remember, the question was whether the Universe is equivalent (or not) to a Turing Machine (and the later, but definition, does not allow time reversal.)
So, the Universe forbids traveling back in time, and a Turing Machine is not a hypercomputing device.
If you can have your infinitely long tape, and infinite time in which to work with it, and infinite space to store it in, and an infinite power supply to run it (even the first movement of the tape would require infinite energy since it's ... well ... infinite), then I can certainly have my reversal of time each second.
That's begging the question. All the prerequisites you have listed do not imply the capacity of moving on the time dimension in a direction opposite to what the laws of physics enforce.
non sequitur
The universe is not a computer problem. The universe is also not a computational device. There's a gaping hole in your argument - the difference between == (equivalency) and === (identity), just as the picture is not the thing.
So by your own admission, the Universe is not Turing Equivalent. And in fact, it's not even comparable. So why then did you ask for a proof that the Universe is not equivalent to a Turing Machine then?
First problem ( of many ) - a representation of something is not that something. This is something that programmers forget all the time. There is no such thing as objects, methods, function calls, etc. Those are just representations. At a higher level, ordering a pizza online, and them sending you a fax of that pizza, is not going to work either. Even them sending you a complete description of the state of every single atom in a pizza is not going to work. Information, contrary to popular belief, is not equivalent to the thing being described.
In other words, even if you had a machine that was able to represent every single state of the universe, it is not equivalent to the universe. Any description of something, no matter how detailed, is not that thing, no matter how many times people chant "information theory says otherwise." It's like the pastor who preaches against same-sex marriage, saying it's unnatural and that same-sex behaviour doesn't occur in nature, but completely ignores the male dog humping his leg.
However, what you offer is not proof by contradiction. It buys into the idea that there's the possibility that the universe might be represented by a Turing machine. That's the flawed premise (but try to get people to see it when they've got their precious theories on the line).
Also, the halting problem is trivially solved by allowing the arrow of time to reverse at the end of each calculation (say once a second), so that even a near-infinite solution must, by definition, complete in 1 second of "real" time. In other words, either the Turing machine continues to exist after one second, or it disappears - stuck in an infinite time loop. This lets you know that the problem is either solvable, or not.
As for the "dude" bit, please see my profile thx bye!
There are so many things wrong and illogical with this post that don't even know where to begin. I will simply focus on the following:
Also, the halting problem is trivially solved by allowing the arrow of time to reverse at the end of each calculation (say once a second)
It's not only trivially solvable by allowing time reversal. At any point where you allow a turing machine to either a) execute an unbounded amount of steps per unit of time, and/or b) execute steps instantaneously (t=0), then it becomes solvable.
Here we are entering the realm of hypercomputability... and I knew it would not take long for a clueless poster to make a mention of it at the sight of the halting problem. You went for the bait just as I predicted it
By your own admission then, the halting problem would require a turing machine to perform an act forbidden by physics. I made a mention of the halting problem with premeditation, to see who would be the first to suggest such an inane thing (inane in the context of whether the Universe is Turing Computable.)
You asked for proof that the Universe is not Turing Computable. I gave you one by demonstrating that one problem in the universe is not turing computable. You can't equate the Universe to a Turing Machine and at the same time allow an uncomputable function be part of it.
Furthermore, you cannot balk at it and say that - and I quote you -
First problem ( of many ) - a representation of something is not that something. This is something that programmers forget all the time. There is no such thing as objects, methods, function calls, etc.
Yes, a representation of something is not that something. But the question was whether the Universe is equivalent to a Turing Machine. That is, whether the Universe is equivalent to a - guess what? - a mathematical representation of a computation device.
By asking to prove it or disprove it, you asked for a proof of the Universe being reduced to a - guess what again? - a mathematical representation of - guess what again? - another mathematical representation of a computing
Aren't the laws of physics axioms for the universe? Isn't the idea behind a grand unified theory to find one or two simple mathematical expressions (axioms) from which the rest of the universe can be derived? The universe is clearly Turing complete, so I really don't see how it wouldn't apply.
How could it be? The universe is naturally uncountable.