But that was the point of the article. Through it's learning process, the AI has developed the decision diagram and there isn't a way to examine it. Suppose for example, the AI knows to stop at a stop light. Does it stop because there is a red light on, or because the top light is lit or a combination of the two or has it "figured out" an entirely different rule? Is there a way to examine the dataset that the AI is using to determine how it makes any particular decision?
Coding and programming are two different things (they are related, but they are different). Coding is learning the syntax of a language and the mechanics of implementing a solution to a problem. Programming is analyzing a problem and determining what computational steps are needed to arrive at a solution.
In the mid 70's, my high school offered a FORTRAN programming class out of the math department. It was a full school year class that met daily. For the coding aspect of the class, we had one shot a week on the computer. On Friday we would hand in our punched cards and on Monday the teacher would return the cards and the compile/run printouts (the computer we used was the school district's main system). The time we spent actually coding was done outside the class room.
The majority of the class however was learning how to program. Coding was a secondary aspect of the class (typically one day a week was going over specific FORTRAN concepts). Our first assignment was to break down the steps one used to make a phone call (step 1, walk over to the phone, step 2 pick up receiver, step 3 listen for a dial tone, step 4 if no dial done...., etc.). We discussed and went over problem solving, algorithms, and how to break a problem down into it's discrete steps. Sometimes the problem was able to be solved without a computer (just analyzing the problem gave the final solution). Our coding assignments were usually stripped down problems that demonstrated that we could actually implement the solution (if I remember correctly, the biggest coding assignment was maybe 50 or so statements long).
In the parent article, it sounds almost the same. They are being introduced on how to program.
In today's environment, there are a lot of coding frameworks that have pre-canned solutions that address many typical programming requirements. So it's easy to approach solving a problem by learning the frameworks and connecting the pieces together. The real programming has already been done within the framework. This is both a blessing and a curse. The blessing is that a lot of people can code a solution to many real-life problems without needing to really understand the programming aspect. The curse is that the solution will more then likely be bloated, and computationally inefficient.
The internet really helps with coding, it acts as a helpful reference for finding frameworks, the syntax of languages and little coding snippets.
Without full company backing, there is little that you can really do. However you can still address some of the security / disaster recovery issues yourself. But first make certain that there is not an existing company policy already in place. The last thing you want to happen, is to start going your own way with security that is against an existing security policy (good way to get fired, or even have a lawsuit thrown at you).
If the business truly doesn't have a security policy, then proceed with setting examples and use best practices. Be careful not to cause more overhead then what the business value of what you are trying to protect.
A good opening discussion with management is to ask them what they value the data or service and how much it would cost them if they couldn't access that data or service any more (or the data is stolen, etc.). Do some homework on risk management. It really boils down to: 1) The value of the thing, 2) the probability of loosing the thing, 3) the cost to protect the thing. The cost of protecting the thing should never exceed the value in relationship to the probability of loosing it.
What you described is nothing more then a full security / disaster recovery audit. If your data center (and management) is really serious about it the company will need to invest both time and money to protect itself.
Create your security policies. This has to be directed from a management level that can put teeth into it, as well as people who understand what the real risks to the business are. Company lawyers and people with business continuity experience might be involved depending on the consequences of what a data breach or disaster might do to the business.
determine what risks your business has
determine what needs to be done to mitigate the identified risks
determine what needs to be logged in order to allow forensic analysis (assume that the compromised system(s) logs themselves may have been corrupted as part of the breach)
Make sure that the policies do not break the business. Also realize that security policies may require some processes to change.
Understand that implementing security polices can be expensive.
Employee education is a necessary step. Make sure employees understand what is being asked of them, and make sure that they understand what the policies are.
Ensure that you have a designated security focal point.
You will probably need an exception process. Make sure that any exceptions are documented with management, what is being done to mitigate any risks the exception have exposed and how long the exception needs to be in place.
Once you have your policies in place and everyone has "signed off" that they are in compliance, you can start with the auditing.
Have some level of auditing where it's a "friendly" review of the systems.
Audits should not instill fear, however there may need to be real consequences for negligent audit failures (depending on the business and type of data).
Depending on the business, you may want to have an independent auditing group come in and review your systems and policies
During an audit, system or process owners should only be held accountable to what is in the security policies. If the audit finds issues that are outside the policies, then management and the policy owner needs to respond.
One additional comment, depending on the size of the organization, there may be a security group. If there is one, then it should be the responsibility of this group to perform any security monitoring or testing. Individuals outside the group should not be performing their own security or intrusion testing of systems that they are not directly responsible for. If a vulnerability is uncovered, it should be documented and reported to the security focal point and management.
James Madison, (you may have remembered his name as he was one of the primary authors of the US Constitution and the Bill of Rights, fourth president of the US, etc..), wrote under the pseudonym Publius a letter that was published in news papers in and around this new group of states. A whole series of these letters and essays, which are now collectively known as the Federalist Papers, were written to help explain to the people why they should ratify this new document and accept this new form of government. The people at that time were a little on the leery side and really didn't have a lot of trust in governments (having just fought a war with England and such).
In the Federalist Paper #46 Madison wrote
The only refuge left for those who prophesy the downfall of the State governments is the visionary supposition that the federal government may previously accumulate a military force for the projects of ambition. The reasonings contained in these papers must have been employed to little purpose indeed, if it could be necessary now to disprove the reality of this danger. That the people and the States should, for a sufficient period of time, elect an uninterupted succession of men ready to betray both; that the traitors should, throughout this period, uniformly and systematically pursue some fixed plan for the extension of the military establishment; that the governments and the people of the States should silently and patiently behold the gathering storm, and continue to supply the materials, until it should be prepared to burst on their own heads, must appear to every one more like the incoherent dreams of a delirious jealousy, or the misjudged exaggerations of a counterfeit zeal, than like the sober apprehensions of genuine patriotism.
Extravagant as the supposition is, let it however be made. Let a regular army, fully equal to the resources of the country, be formed; and let it be entirely at the devotion of the federal government; still it would not be going too far to say, that the State governments, with the people on their side, would be able to repel the danger. The highest number to which, according to the best computation, a standing army can be carried in any country, does not exceed one hundredth part of the whole number of souls; or one twenty-fifth part of the number able to bear arms. This proportion would not yield, in the United States, an army of more than twenty-five or thirty thousand men. To these would be opposed a militia amounting to near half a million of citizens with arms in their hands, officered by men chosen from among themselves, fighting for their common liberties, and united and conducted by governments possessing their affections and confidence. It may well be doubted, whether a militia thus circumstanced could ever be conquered by such a proportion of regular troops. Those who are best acquainted with the last successful resistance of this country against the British arms, will be most inclined to deny the possibility of it. Besides the advantage of being armed, which the Americans possess over the people of almost every other nation, the existence of subordinate governments, to which the people are attached, and by which the militia officers are appointed, forms a barrier against the enterprises of ambition, more insurmountable than any which a simple government of any form can admit of. Notwithstanding the military establishments in the several kingdoms of Europe, which are carried as far as the public resources will bear, the governments are afraid to trust the people with arms. And it is not certain, that with this aid alone they would not be able to shake off their yokes. But were the people to possess the additional advantages of local governments chosen by themselves, who could collect the national will and direct the national force, and of officers appointed out of the militia, by these governments, and attached both to them and to the militia, it may be affirmed with the greatest assurance, that the throne of every tyranny in Europe w
A DMCA takedown notice for something that doesn't belong to you is simply theft, and should be treated as such. If the whole purpose of DMCA is to protect the owner of some property, it needs to work both ways.
If I called a towing company claimed that the car you had parked in your driveway was mine and that I wanted it towed to my house, that would be theft.
No one is expecting management to come in and fight the fire at 2 AM. What is expected of management however is for them to understand what is happening within their organization (and not at the bit's and bytes level) because they are directly responsible for the actual organization. What management should be able to do is to be able to bring in another competent person to fix the fire at 11 AM because you were killed on the highway while you were driving into the office at 2. And that competent person should be able to get a start fixing that problem because management was able to give them the proper "keys" and there is proper documentation for them to get a gist of the layout of the system.
Yes -- you are a sysop, and not management. You are an employee hired to perform what management wants. If management screws up and something happens to the organization, they can be legally held responsible -- think Sorbanes Oxley, if you are following their orders then you are off the hook (one of the reasons why executives are paid the salaries that they are). If you go off and do something on your own without their approval, or try to hide things from them under the guise of "I know what's right for the business", and something happens it will be your butt on the line.
Say that you worked in a finance group responsible for transferring company assets into different external funds that are dictated by upper management, and you thought "hey upper management doesn't understand what they are doing and they don't listen to me, I'm going to go out and transfer some of the companies money into some the funds that I think are doing well, and I know it can make a huge return of investment for the company". How far do you think your arguments would float?
One of the things is that sysops and admins need to stop "hiding" the incompetencies of management by "by going behind management and doing the right thing". If you really believe that the organization is going to fail because of management decisions, document what those decisions are, document how you believe that they are harming the organization and report it to the organization's internal auditing or business controls folks.
1.2 Avoid harm to others - which includes whistle blowing if you believe that superiors are not acting to mitigate a problem that could harm others, but it also means that you've done all the homework as well and taking responsibility of your actions.
2.5 Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks.
2.6 Honor contracts, agreements, and assigned responsibilities.
2.8 Access computing and communication resources only when authorized to do so.
All in all I believe that if you really read full list of the ethics of these types of organizations you will find that if you are doing your job well, properly documenting any issues, validating problems, and responsibly reporting them, incompetency will not have a leg to stand on.
Properly documented policies could have helped in this situation.
A policy should have been in place that defined who the business owner (management) of the resource was (network in this case). It is the responsibility of management to ensure that they define who has a business need for access (and have it documented), and it's the responsibility of the tech grunt to run the system (or network) for the business owner.
The key point is that as a non-manager type person, if management says jump, get it in writing and jump. Management is ultimately responsible for the system and network to the business. If management has made bad choices or decisions, it's their fault and if the request or actions leading up to the failure are documented, that admin can refer to that.
All organizations should at least have a documented policy of who can have access to resources and that the business owner of the resource can be easily determined. The business owner needs to be someone who is legally responsible to the organization (i.e. an executive, or someone high enough in management).
As a system administrator, you should insist on having this documented just to protect yourself. If you suspect that there is some management decisions that could jeopardize the operation of the system, document it, report it to the business owner and let them make the final decision (with documentation).
In the case of Terry Childs, had this been documented, he would have been able to either say that the person who was requesting the passwords did not have a business need (and would be able to back that statement with documentation), -or- if the person did have authority to have access, he could have simply have documented why it was a bad decision, hand the passwords over and walk away from it.
Yes there is a pride element. You've spent years building up a system and making it shine, but unless you are running your own business, you are not the legal owner of that system.
The only way that I would get rid of my Model M Keyboard (and the stash of spares), would be if someone came out with a keyboard that had the same key action/feel as the old IBM 327x keyboards (which you could use as an anti-tank barrier). The Selectric keyboard had just about the same tactile feel as the 3270s, not quite the same, but close.
so yes -- I fully understand your feeling about your keyboard... they can have my Model M keyboard when they can pry it from my cold dead hands.
Nothing new.. please move along
on
Knuth Got It Wrong
·
· Score: 3, Informative
This really isn't anything new. Knuth didn't get it "wrong". He based his analysis of the algorithms assuming a system that had dedicated memory and where each instruction of code ran uninterrupted and in a consistent fashion.
Certain memory access patterns are "bad" under a system that uses virtual memory, especially when the base system is memory constrained. This has been a well known fact for decades. In fact one of the maybe lost arts of programming was ensuring reference locality, not only of data, but also of code. It was a common practice to ensure that often called subroutines or functions where either located in same page of memory as the calling code, or to group all the often called functions into as few pages of memory as possible.
Basically, every address space has what is sometimes called a working set, a set of pages that have been recently referenced. There are three things that can happen with a working set. It can remain the same size, it can grow and it can shrink. If it remains the same, there is no additional load to the operating system. If it shrinks, there is no additional load to the operating system, in fact this can help a memory constrained system. A growing working set however an lead to a thrashing system. Some operating systems will monitor working set sizes and can adjust dispatch priorities and execution classes depending on what the recent working set size history is. An application with a growing working set may very will find itself at the end of the queue way behind applications that have a static working set size.
Take for an example the following very simple program
static string buffer[256][4096] while not infile.eof() do infile.readinto(buffer[0],256) outfile.writefrom(buffer[0],256) end
Here the working set of this program will be very small. Ignoring the file i/o routines, all the code and data references will be limited to basically a fixed section of memory. From a virtual memory stand point, this is a "well behaved" application.
Now take the following
static string buffer[256][4096] while not infile.eof() do bindex = random(0,4095) infile.readinto(buffer[ bindex ], 256) outfile.wwritefrom(buffer[ bindex ], 256) end
Functionally the same program, however the data reference pattern here is all over the place. The working set will be large, since many of the buffer pages will be referenced. The program never stays long on the same memory location.
Finally take the following example
static string buffer[256][4096] infile.readinto(buffer[0], 256* 4096)// fill the entire buffer for i = 0 to 4095 do numbercrunch( buffer[i] ) end
Here there will be an initially huge working set as the data is read in. However, the working set will shrink to a reasonable size once the numbercrunching phase starts since the data references will all be localized to a small block of memory.
Understand (and thanks for the fleshed out details).. it's a nasty event that is putting a strain on the environment.
People on both sides of the argument should at least realize that they don't have all the "answers". The folks that are saying "it's no big deal", need to realize the concentration and location of the spill will have a local impact to the environment and the local economy, that even though there are natural processes that "spill oil into the environment", this event is straining the system. The folks that are saying "it's the end of the world", need to understand that there are some natural processes that can have similar impacts, and that in the very long run the environment will recover (just not in the time scale that one might expect). I would say instead of arguing or putting heads into sand, people should just get in and "clean it up" to the best of our ability, and make sure that reasonable safeguards are put in place to ensure future events such as this can't happen.
Basically the natural seepage in the northern Golf of Mexico it's about 120,000 barrels a year. For the entire Golf of Mexico it's about 625-1,875 barrels a day (or 2.5 to 6.9 x 10^5 barrels a year).
The "problem" I suspect with the current oil well is the localization of the spill, and thus higher concentrations of the oil. Kind of like trying to eat a teaspoon of hot sauce directly versus adding a teaspoon of hot sauce to a bowl of chili. It's the same amount of the stuff, just dispersed over a larger area.
I just wish that the US population would get over the general reaction to anything is to sue someone.
If you can't take a little bloody nose, maybe you ought to go back home and crawl under your bed. It's not safe out here. It's wondrous, with treasures to satiate desires both subtle and gross. But it's not for the timid. Q - "Q Who" Star Trek the Next Generation
Different fuel, but basically the same idea as a carbide cannon which has been around for at least 100 years. In fact there was a patent from the early 1900's (US 874,952) on an improved gas gun.
So, basically all that is new is the recharge time and the decibels.
The evolution of VM from CP/67 to z/VM has resulted in some of the virtualization function being pushed down into the hardware.
With the introduction of XA architecture in the late 80's, IBM moved some of the virtualization technology down into the hardware, they created a new instruction, SIE - Start Interpretive Execution that could tap into this facility. This facility ended up being the heart of both LPARs and VM/XA (which grew into current z/VM). Conceptually the SIE instruction, or the LPAR facility saves the current processor context, and starts a new context. The "guest" system (or the LPAR) now runs in this new context until some condition has been met (e.g. certain timer pops, certain state changes, etc, as defined by the meta-system (z/VM or the base system managing the LPARs). The movement of this function down into hardware was a logical extension of what used to be called hardware VM assists in pre-XA days.
Basically the base hardware provides LPARs (in fact for quite some time IBM mainframes can only run in LPAR mode, even if one has only one system image). LPARs allow sharing of the physical processors, sharing of physical I/O devices, and partitioning of physical memory. With an LPAR you cannot exceed the physical resources available, meaning that you cannot define an LPAR image with more processors then are physically available, or give an LPAR image more memory then is physically available. This is where z/VM comes in.
z/VM provides the ability to virtualize the physical resources. You can define a VM guest with more memory then is physically available, or more processors then are physically available. In addition z/VM can provide virtualized I/O devices, or provide more fine grained partitioning of physical devices (e.g. carving a disk volume into a collecting of smaller volumes in what is called mini-disks -- which are not the same as a disk partition).
The whole purpose of comments is to explain the code so that future maintainers (including the author of the code) can easily understand what is going on. If done right, a maintainer can pick up a module and come up to speed as to what the code does, why it does it, and any thing else that might trip them up. Comments need to capture the developers thoughts from when the code was being designed and written. The reasoning and ideas behind an algorithm that took several months to design cannot be truly captured with a 3 line comment and 25 lines of code.
I feel that comments can be broken into four types:
Boiler plate front matter. These are the comments that are required by the coding standards of the shop. Usually contains copyright notices, author's name, list of changes, etc.
Specification and reference comments. A list of the external references, such as the formal specification for the code, a bibliography for the algorithms used, etc.
Block comments. These should describe the intent of a larger block of code. The reader should be able to take all the block comments from a program and have a good understanding what the entire program does. Block comments should describe the what and why. Block comments should also describe any gotchas, or special conditions that the maintainer needs to be aware of.
Line comments. Should describe the purpose of a small number of statements. Line comments should not merely echo the action of the code itself, but describe what is happening and how the particular action relates to the rest of the program.
Tesla actually demonstrated it. He just never got the chance to scale it up.
So.. before going around and saying that this has just been invented, go check Tesla's patents.
Several years ago I read (and wish I remembered where) a technique that I thought was quite interesting. It was a rule based authentication scheme. Each account on a system would have it's own set of rules that only the user would know. For example.
login: myid
What is 2+4?:cat
Here I might have set up the rule to say whenever there is a mathematical equation, with an even result and it's in the morning enter "cat", if it's in the afternoon enter "river", if the result is odd and it's monday then enter "blue", tuesday enter... you get the idea.
The response has nothing to do mathematically with the question, but relies on the fact that I know what the proper response should be. And even is someone was watching my response. Each time I log in a different rule would be used (maybe the next question would be "what color are roses?")
Personally if I were to make the decisions on hiring someone, and give the choice between a person who knew only one language inside and out and a person who was exposed to 4 or 5 different language but needed a quick peek at a reference book to make sure they got the syntax right or some such, I would pick the 2nd person without even blinking.
You see, to the first person, he has only one tool in his tool box (a hammer), and to him everything will look like a nail.
Programming is so much more then just simply banging out a bunch of lines of code. It's looking at the requirements and picking the best tool for the job. In addition things are never static. A little tool may be needed and python may just fit the bill, then there will be that web application that needs enhanced and that is written in PHP, and the boss just dropped by and said that corporate just got a new application in and it has it's own scripting interface and it needs in interface to the application that you are responsible for.
Sure... if you are working on a big project, that project may have decided to use just one language and you will spend the next 3 years looking at java, but knowing how a computer really works (from that assembly class - even though you've never code a single line of assembly) you can make some wise decisions on how to implement something, or maybe just maybe you might come back and say - you know right here it would be beneficial to call out to a routine written in C because Java just isn't going to cut it right here.
Ah... the constitution does not enumerate the rights that we have, but lists what rights the government has. The bill of rights explicitly spells out those things that the government cannot take away. The 9th and 10th amendments spell this out
Amendment 9
The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people.
Amendment 10
The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
I'd give her a little more credit... I don't know all the details but reading the "Caroline's story" it does sound like she was capturing and processing the images herself (with some assistence in getting going and learning what to do). It might have been "Dad's" observatory and such.. but it still looks like she was doing the work. The co-discovery might simply have been the "hey let me check my data as well..".
The setup that some of these SN hunters is fairly automated, they maintain a list of objects that they will check on a routine basis. A group of SN hunters will sometimes pool their resources, share lists, coordinate what objects they are going to check, etc. The scopes can be automated to jump from object to object, take some exposures, then move on to the next object. The processing of the exposures can be partially automated, but it still requires going through them to determine if it's real or an imaging artifict or a cosmic ray on the image. This used to be done by using an optical blink comparitor (an old school optical box set up where you can quickly flip from viewing one photographic plate to another)
Anyway -- Kudos to Caroline. It's a fun hobby that has been keeping me busy since I was 12 and had access to a 10" Newtonian.
Slashdot Mirror
But that was the point of the article. Through it's learning process, the AI has developed the decision diagram and there isn't a way to examine it. Suppose for example, the AI knows to stop at a stop light. Does it stop because there is a red light on, or because the top light is lit or a combination of the two or has it "figured out" an entirely different rule? Is there a way to examine the dataset that the AI is using to determine how it makes any particular decision?
is it line noise, or is it TECO?
Coding and programming are two different things (they are related, but they are different). Coding is learning the syntax of a language and the mechanics of implementing a solution to a problem. Programming is analyzing a problem and determining what computational steps are needed to arrive at a solution.
In the mid 70's, my high school offered a FORTRAN programming class out of the math department. It was a full school year class that met daily. For the coding aspect of the class, we had one shot a week on the computer. On Friday we would hand in our punched cards and on Monday the teacher would return the cards and the compile/run printouts (the computer we used was the school district's main system). The time we spent actually coding was done outside the class room.
The majority of the class however was learning how to program. Coding was a secondary aspect of the class (typically one day a week was going over specific FORTRAN concepts). Our first assignment was to break down the steps one used to make a phone call (step 1, walk over to the phone, step 2 pick up receiver, step 3 listen for a dial tone, step 4 if no dial done ...., etc.). We discussed and went over problem solving, algorithms, and how to break a problem down into it's discrete steps. Sometimes the problem was able to be solved without a computer (just analyzing the problem gave the final solution). Our coding assignments were usually stripped down problems that demonstrated that we could actually implement the solution (if I remember correctly, the biggest coding assignment was maybe 50 or so statements long).
In the parent article, it sounds almost the same. They are being introduced on how to program.
In today's environment, there are a lot of coding frameworks that have pre-canned solutions that address many typical programming requirements. So it's easy to approach solving a problem by learning the frameworks and connecting the pieces together. The real programming has already been done within the framework. This is both a blessing and a curse. The blessing is that a lot of people can code a solution to many real-life problems without needing to really understand the programming aspect. The curse is that the solution will more then likely be bloated, and computationally inefficient.
The internet really helps with coding, it acts as a helpful reference for finding frameworks, the syntax of languages and little coding snippets.
Without full company backing, there is little that you can really do. However you can still address some of the security / disaster recovery issues yourself. But first make certain that there is not an existing company policy already in place. The last thing you want to happen, is to start going your own way with security that is against an existing security policy (good way to get fired, or even have a lawsuit thrown at you). If the business truly doesn't have a security policy, then proceed with setting examples and use best practices. Be careful not to cause more overhead then what the business value of what you are trying to protect. A good opening discussion with management is to ask them what they value the data or service and how much it would cost them if they couldn't access that data or service any more (or the data is stolen, etc.). Do some homework on risk management. It really boils down to: 1) The value of the thing, 2) the probability of loosing the thing, 3) the cost to protect the thing. The cost of protecting the thing should never exceed the value in relationship to the probability of loosing it.
What you described is nothing more then a full security / disaster recovery audit. If your data center (and management) is really serious about it the company will need to invest both time and money to protect itself.
Once you have your policies in place and everyone has "signed off" that they are in compliance, you can start with the auditing.
One additional comment, depending on the size of the organization, there may be a security group. If there is one, then it should be the responsibility of this group to perform any security monitoring or testing. Individuals outside the group should not be performing their own security or intrusion testing of systems that they are not directly responsible for. If a vulnerability is uncovered, it should be documented and reported to the security focal point and management.
James Madison, (you may have remembered his name as he was one of the primary authors of the US Constitution and the Bill of Rights, fourth president of the US, etc..), wrote under the pseudonym Publius a letter that was published in news papers in and around this new group of states. A whole series of these letters and essays, which are now collectively known as the Federalist Papers, were written to help explain to the people why they should ratify this new document and accept this new form of government. The people at that time were a little on the leery side and really didn't have a lot of trust in governments (having just fought a war with England and such).
In the Federalist Paper #46 Madison wrote
I wish I had some mod points.
Mel's story is a wonderful example.
If I called a towing company claimed that the car you had parked in your driveway was mine and that I wanted it towed to my house, that would be theft.
If I add in my phone... stock android -> Cyanogenmod
Ah, so your'e fine with a Perl script with some undecipherable regular expressions.... It's all a matter of perspective..
No one is expecting management to come in and fight the fire at 2 AM. What is expected of management however is for them to understand what is happening within their organization (and not at the bit's and bytes level) because they are directly responsible for the actual organization. What management should be able to do is to be able to bring in another competent person to fix the fire at 11 AM because you were killed on the highway while you were driving into the office at 2. And that competent person should be able to get a start fixing that problem because management was able to give them the proper "keys" and there is proper documentation for them to get a gist of the layout of the system.
Yes -- you are a sysop, and not management. You are an employee hired to perform what management wants. If management screws up and something happens to the organization, they can be legally held responsible -- think Sorbanes Oxley, if you are following their orders then you are off the hook (one of the reasons why executives are paid the salaries that they are). If you go off and do something on your own without their approval, or try to hide things from them under the guise of "I know what's right for the business", and something happens it will be your butt on the line.
Say that you worked in a finance group responsible for transferring company assets into different external funds that are dictated by upper management, and you thought "hey upper management doesn't understand what they are doing and they don't listen to me, I'm going to go out and transfer some of the companies money into some the funds that I think are doing well, and I know it can make a huge return of investment for the company". How far do you think your arguments would float?
One of the things is that sysops and admins need to stop "hiding" the incompetencies of management by "by going behind management and doing the right thing". If you really believe that the organization is going to fail because of management decisions, document what those decisions are, document how you believe that they are harming the organization and report it to the organization's internal auditing or business controls folks.
The code of ethics for the ACM includes the following http://www.acm.org/about/code-of-ethics
All in all I believe that if you really read full list of the ethics of these types of organizations you will find that if you are doing your job well, properly documenting any issues, validating problems, and responsibly reporting them, incompetency will not have a leg to stand on.
A policy should have been in place that defined who the business owner (management) of the resource was (network in this case). It is the responsibility of management to ensure that they define who has a business need for access (and have it documented), and it's the responsibility of the tech grunt to run the system (or network) for the business owner.
The key point is that as a non-manager type person, if management says jump, get it in writing and jump. Management is ultimately responsible for the system and network to the business. If management has made bad choices or decisions, it's their fault and if the request or actions leading up to the failure are documented, that admin can refer to that.
All organizations should at least have a documented policy of who can have access to resources and that the business owner of the resource can be easily determined. The business owner needs to be someone who is legally responsible to the organization (i.e. an executive, or someone high enough in management).
As a system administrator, you should insist on having this documented just to protect yourself. If you suspect that there is some management decisions that could jeopardize the operation of the system, document it, report it to the business owner and let them make the final decision (with documentation).
In the case of Terry Childs, had this been documented, he would have been able to either say that the person who was requesting the passwords did not have a business need (and would be able to back that statement with documentation), -or- if the person did have authority to have access, he could have simply have documented why it was a bad decision, hand the passwords over and walk away from it.
Yes there is a pride element. You've spent years building up a system and making it shine, but unless you are running your own business, you are not the legal owner of that system.
The only way that I would get rid of my Model M Keyboard (and the stash of spares), would be if someone came out with a keyboard that had the same key action/feel as the old IBM 327x keyboards (which you could use as an anti-tank barrier). The Selectric keyboard had just about the same tactile feel as the 3270s, not quite the same, but close. so yes -- I fully understand your feeling about your keyboard... they can have my Model M keyboard when they can pry it from my cold dead hands.
This really isn't anything new. Knuth didn't get it "wrong". He based his analysis of the algorithms assuming a system that had dedicated memory and where each instruction of code ran uninterrupted and in a consistent fashion.
Certain memory access patterns are "bad" under a system that uses virtual memory, especially when the base system is memory constrained. This has been a well known fact for decades. In fact one of the maybe lost arts of programming was ensuring reference locality, not only of data, but also of code. It was a common practice to ensure that often called subroutines or functions where either located in same page of memory as the calling code, or to group all the often called functions into as few pages of memory as possible.
Basically, every address space has what is sometimes called a working set, a set of pages that have been recently referenced. There are three things that can happen with a working set. It can remain the same size, it can grow and it can shrink. If it remains the same, there is no additional load to the operating system. If it shrinks, there is no additional load to the operating system, in fact this can help a memory constrained system. A growing working set however an lead to a thrashing system. Some operating systems will monitor working set sizes and can adjust dispatch priorities and execution classes depending on what the recent working set size history is. An application with a growing working set may very will find itself at the end of the queue way behind applications that have a static working set size.
Take for an example the following very simple program
Here the working set of this program will be very small. Ignoring the file i/o routines, all the code and data references will be limited to basically a fixed section of memory. From a virtual memory stand point, this is a "well behaved" application.
Now take the following
Functionally the same program, however the data reference pattern here is all over the place. The working set will be large, since many of the buffer pages will be referenced. The program never stays long on the same memory location.
Finally take the following example
Here there will be an initially huge working set as the data is read in. However, the working set will shrink to a reasonable size once the numbercrunching phase starts since the data references will all be localized to a small block of memory.
People on both sides of the argument should at least realize that they don't have all the "answers". The folks that are saying "it's no big deal", need to realize the concentration and location of the spill will have a local impact to the environment and the local economy, that even though there are natural processes that "spill oil into the environment", this event is straining the system. The folks that are saying "it's the end of the world", need to understand that there are some natural processes that can have similar impacts, and that in the very long run the environment will recover (just not in the time scale that one might expect). I would say instead of arguing or putting heads into sand, people should just get in and "clean it up" to the best of our ability, and make sure that reasonable safeguards are put in place to ensure future events such as this can't happen.
Basically the natural seepage in the northern Golf of Mexico it's about 120,000 barrels a year. For the entire Golf of Mexico it's about 625-1,875 barrels a day (or 2.5 to 6.9 x 10^5 barrels a year).
The "problem" I suspect with the current oil well is the localization of the spill, and thus higher concentrations of the oil. Kind of like trying to eat a teaspoon of hot sauce directly versus adding a teaspoon of hot sauce to a bowl of chili. It's the same amount of the stuff, just dispersed over a larger area.
I just wish that the US population would get over the general reaction to anything is to sue someone.
If you can't take a little bloody nose, maybe you ought to go back home and crawl under your bed. It's not safe out here. It's wondrous, with treasures to satiate desires both subtle and gross. But it's not for the timid. Q - "Q Who" Star Trek the Next Generation
One of my favorite quotes.
So, basically all that is new is the recharge time and the decibels.
With the introduction of XA architecture in the late 80's, IBM moved some of the virtualization technology down into the hardware, they created a new instruction, SIE - Start Interpretive Execution that could tap into this facility. This facility ended up being the heart of both LPARs and VM/XA (which grew into current z/VM). Conceptually the SIE instruction, or the LPAR facility saves the current processor context, and starts a new context. The "guest" system (or the LPAR) now runs in this new context until some condition has been met (e.g. certain timer pops, certain state changes, etc, as defined by the meta-system (z/VM or the base system managing the LPARs). The movement of this function down into hardware was a logical extension of what used to be called hardware VM assists in pre-XA days.
Basically the base hardware provides LPARs (in fact for quite some time IBM mainframes can only run in LPAR mode, even if one has only one system image). LPARs allow sharing of the physical processors, sharing of physical I/O devices, and partitioning of physical memory. With an LPAR you cannot exceed the physical resources available, meaning that you cannot define an LPAR image with more processors then are physically available, or give an LPAR image more memory then is physically available. This is where z/VM comes in.
z/VM provides the ability to virtualize the physical resources. You can define a VM guest with more memory then is physically available, or more processors then are physically available. In addition z/VM can provide virtualized I/O devices, or provide more fine grained partitioning of physical devices (e.g. carving a disk volume into a collecting of smaller volumes in what is called mini-disks -- which are not the same as a disk partition).
I feel that comments can be broken into four types:
Tesla actually demonstrated it. He just never got the chance to scale it up. So.. before going around and saying that this has just been invented, go check Tesla's patents.
Several years ago I read (and wish I remembered where) a technique that I thought was quite interesting. It was a rule based authentication scheme. Each account on a system would have it's own set of rules that only the user would know. For example.
login: myid
What is 2+4?:cat
Here I might have set up the rule to say whenever there is a mathematical equation, with an even result and it's in the morning enter "cat", if it's in the afternoon enter "river", if the result is odd and it's monday then enter "blue", tuesday enter ... you get the idea.
The response has nothing to do mathematically with the question, but relies on the fact that I know what the proper response should be. And even is someone was watching my response. Each time I log in a different rule would be used (maybe the next question would be "what color are roses?")
Personally if I were to make the decisions on hiring someone, and give the choice between a person who knew only one language inside and out and a person who was exposed to 4 or 5 different language but needed a quick peek at a reference book to make sure they got the syntax right or some such, I would pick the 2nd person without even blinking.
You see, to the first person, he has only one tool in his tool box (a hammer), and to him everything will look like a nail.
Programming is so much more then just simply banging out a bunch of lines of code. It's looking at the requirements and picking the best tool for the job. In addition things are never static. A little tool may be needed and python may just fit the bill, then there will be that web application that needs enhanced and that is written in PHP, and the boss just dropped by and said that corporate just got a new application in and it has it's own scripting interface and it needs in interface to the application that you are responsible for.
Sure... if you are working on a big project, that project may have decided to use just one language and you will spend the next 3 years looking at java, but knowing how a computer really works (from that assembly class - even though you've never code a single line of assembly) you can make some wise decisions on how to implement something, or maybe just maybe you might come back and say - you know right here it would be beneficial to call out to a routine written in C because Java just isn't going to cut it right here.
Amendment 9 The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people. Amendment 10 The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
I'd give her a little more credit... I don't know all the details but reading the "Caroline's story" it does sound like she was capturing and processing the images herself (with some assistence in getting going and learning what to do). It might have been "Dad's" observatory and such.. but it still looks like she was doing the work. The co-discovery might simply have been the "hey let me check my data as well..".
The setup that some of these SN hunters is fairly automated, they maintain a list of objects that they will check on a routine basis. A group of SN hunters will sometimes pool their resources, share lists, coordinate what objects they are going to check, etc. The scopes can be automated to jump from object to object, take some exposures, then move on to the next object. The processing of the exposures can be partially automated, but it still requires going through them to determine if it's real or an imaging artifict or a cosmic ray on the image. This used to be done by using an optical blink comparitor (an old school optical box set up where you can quickly flip from viewing one photographic plate to another)
Anyway -- Kudos to Caroline. It's a fun hobby that has been keeping me busy since I was 12 and had access to a 10" Newtonian.