However, there is no good reason to run a telnet daemon these days, especially on the public Internet.
Interesting you should say that, because the article actually says they don't know if it's brute force login attempts or botnet traffic. A largely unused port with traffic that most people ignore makes sense to park a botnet on. It makes a lot more sense than a sudden spike in system administrator incompetence, which means most of the comments on this story are likely off the mark.
This state of the union address contains forward-looking statements which reflect the administration's best judgment based on factors currently known. However, these statements involve risks and uncertainties, including a Republican-controlled House, talk radio, the tea party, as yet undiscovered problems to blame Bush for, and other risks detailed in our annual report on Form 10-K for the year ended December 31, 2009 and our quarterly report on Form 10-Q for the quarter ended September 30, 2010. These risks and uncertainties could cause actual results to differ materially from those in the forward-looking statements included in this speech.
Because it lets you focus your time on what makes your site unique, instead of on reinventing functionality that's common to 99% of all the sites out there. Throwing away 90 thousand lines of widely used, production tested code to make your own is rarely easier by any stretch of the word.
I know what you mean. Slashdot, facebook, yahoo, wikipedia, whitehouse.gov, and all those other low-traffic scripting language powered websites are mere amateurish attempts. I demand a professional C++ website like, uh, help me out here...
Maybe you should do some research before making claims. AppArmor is included by default on Ubuntu and allows application level internet permissions. Granted, it is configured very liberally by default, and I'm not aware of an easy GUIfied way for end users to grant exceptions. That's a plus in my book, though. Any system administrator is free to lock it down as tight as they want, and if the general populace of Linux users starts running untrusted software willy nilly instead of using the package manager, a strengthening of defaults is only an update away.
Also, AppArmor handles the reverse functionality very well, which is arguably more important: software that is allowed to connect to the internet can be restricted in other ways. For example, I can set up a folder that is completely invisible to internet connected applications for storing sensitive data in.
Hopefully, at this point they can figure out how to use a GUI by trial and error. I would introduce them to the customizability not available on Windows with being able to choose Gnome, KDE, Unity, Avant Window Navigator, etc. Also little niceties like middle click pasting, multiple desktops, and focus follows mouse that they may have never seen.
Since they are CS students, I would also cover the basics of developing on Linux that may be unfamiliar:
configure, make, make install
dev packages versus runtime packages
Setting up autoconf
Directory hierarchy
Intro to major CLI based text editors: vim, emacs, nano, etc.
Intro to CLI based source control: git, hg, svn, bzr, etc.
Overview of graphical toolkits and how to link software with them: Qt, Gtk, etc.
Basically, cover enough so when a professor gives them a programming assignment in subsequent semesters, they should be able to focus on the code more than the operating system. A typical assignment toward the end of the class would reflect mastery of the development environment but require little programming expertise, something like "create a.deb package containing a program that displays hello world in a Gtk window" or "submit a git bundle with a change from hello world to hey there world."
Are you kidding? Debt is transferred all the time. Have you never sold a savings bond?
Also, sovereign debt isn't revolving like a credit card. It has fixed terms and needs to be refinanced all the time. Just China stopping buying new debt would have significant repercussions.
Zero day refers to how much time an administrator has to patch his systems before an exploit is known. Since this is still not patched, it is indeed a zero day exploit, although if the exploit is as yet unused it is not a zero day attack.
I completely agree about needing a basic understanding of reading and writing math first. I haven't seen the inside of a math classroom in many years, and my work doesn't involve a lot of "heavy" math, but I use basic algebra at work fairly regularly. Recently, an acquaintance of mine in a college algebra class commented that she understood most of the class really well except for the "word problems." I hadn't heard that phrase in so long that I had forgotten it existed. All the math I do is "word problems" and it is utterly useless to me otherwise. It astounded me that someone could consider themselves good at math when they didn't even have the basic skill of being able to transcribe back and forth between math and english.
Probably because they never took that class. I can imagine management saying, "This one doesn't have a light, so we don't need electrical engineering to approve the design, only mechanical." That sort of thing happens at my work more often than I would expect, going both ways.
At her insistence, a blue e opened my wife's web browser for a year or so after we switched to Linux. That was pre-firefox, I think it was just plain mozilla suite web browser.
Last week, she bought some sort of device to make Skype calls from our regular phone and manually installed the device driver and userspace daemon, all without my input at all. I couldn't be more proud:-)
Unless you're foregoing those items altogether, you're probably not saving any money. Testers have significantly lower salaries than programmers. When a programmer does all the testing, you are paying programmer rates for testing work.
You're both missing the point here. Knowing the current commute time is fairly easy. The tricky part is using the measurements now to predict the commute times an hour from now. My commute ranges from 20 up to 50 minutes or so. If I can look on a website and see in a half hour my commute will be a half hour shorter, I'll just wait. If it's still going to be long, I'd rather slog it out now and get it over with.
I hate to break it to you, but even if your trunk is clean, you will still have this problem in some other branch. Let's examine a very common situation where you have an interface being changed, one or more implementations of that interface, and one or more users of that interface. Developers are working simultaneously on both sides of that interface in order to meet a deadline.
Because of your clean trunk rule, none of the changes can be checked into the trunk until all of the changes are ready, but they still need to be shared among the people working on it, or they will have no idea if it is "good and ready." So those developers create their own branch, which of necessity is sometimes in a temporarily broken state. You might not think of it as a branch, if it's John's working directory and the "checkout" procedure is him emailing files around, but it's conceptually a branch nonetheless.
Linus is simply acknowledging that temporary brokenness is inevitable when multiple people integrate changes to the same code, and therefore whatever branch contains that messy integration should use tags to communicate the best branch points. I'm not saying keeping a clean trunk isn't a good idea, just that you have to deal with broken branch points one way or another, even if it's just John deciding when the best time is to email out the new header files to his team.
from the system's point of view it's the same as if someone climbed up on their roof
True, but irrelevant. Climbing on the roof is still better for the individual at the expense of the system. Just because behavior is accepted and accounted for doesn't make it optimal.
I make a living writing embedded software for telecommunications equipment and am also a ham radio operator, so I have a hard time seeing why this isn't blindingly obvious to everyone, but if you want more wireless bandwidth and less congestion, each individual's signal must have the lowest power necessary for reliable communication.
For example, say you have 100 cell phones in active use at any given time in your neighborhood. If every cell phone signal in that neighborhood is boosted to be able to cover the entire neighborhood, each subscriber necessarily is limited to 1% of the available wireless bandwidth for that neighborhood. If you limit each signal to the walls of a person's home, every individual gets 100 times more bandwidth because they aren't competing with their neighbors. You can always lay more fiber to increase bandwidth. Increased wireless bandwidth is only possible by limited technological improvements. That's an over-simplification, but you get my point.
Boosting an individual's signal may be temporarily good for that individual, but bad for the system. There are alternatives that are good for both the individual and the system. Hence, the desire for regulation.
That's because people who don't know what they are doing don't know that they don't know what they're doing. Those types of comments should be accompanied by a clear competence or acceptance test. For example, the last such comment I wrote went something like:/* This might look like an unnecessary delay, but the timing has been carefully calibrated against a wide range of marginal real world conditions. If you touch this function, you must ensure it does not time out under these configurations... */
In other words, "knowing what you're doing" must be definable and transferable knowledge.
I had thought it was part of the same process in Ubuntu that prompts to install other proprietary drivers like nvidia, but maybe it's a future plan I remember reading. The last time I did it myself was 3 years ago. Starting up ndisgtk and browsing to the.inf file is more than one click, but I'd hardly call it "messing with configs."
Slashdot Mirror
Interesting you should say that, because the article actually says they don't know if it's brute force login attempts or botnet traffic. A largely unused port with traffic that most people ignore makes sense to park a botnet on. It makes a lot more sense than a sudden spike in system administrator incompetence, which means most of the comments on this story are likely off the mark.
This state of the union address contains forward-looking statements which reflect the administration's best judgment based on factors currently known. However, these statements involve risks and uncertainties, including a Republican-controlled House, talk radio, the tea party, as yet undiscovered problems to blame Bush for, and other risks detailed in our annual report on Form 10-K for the year ended December 31, 2009 and our quarterly report on Form 10-Q for the quarter ended September 30, 2010. These risks and uncertainties could cause actual results to differ materially from those in the forward-looking statements included in this speech.
Because it lets you focus your time on what makes your site unique, instead of on reinventing functionality that's common to 99% of all the sites out there. Throwing away 90 thousand lines of widely used, production tested code to make your own is rarely easier by any stretch of the word.
I know what you mean. Slashdot, facebook, yahoo, wikipedia, whitehouse.gov, and all those other low-traffic scripting language powered websites are mere amateurish attempts. I demand a professional C++ website like, uh, help me out here...
Maybe you should do some research before making claims. AppArmor is included by default on Ubuntu and allows application level internet permissions. Granted, it is configured very liberally by default, and I'm not aware of an easy GUIfied way for end users to grant exceptions. That's a plus in my book, though. Any system administrator is free to lock it down as tight as they want, and if the general populace of Linux users starts running untrusted software willy nilly instead of using the package manager, a strengthening of defaults is only an update away.
Also, AppArmor handles the reverse functionality very well, which is arguably more important: software that is allowed to connect to the internet can be restricted in other ways. For example, I can set up a folder that is completely invisible to internet connected applications for storing sensitive data in.
Hopefully, at this point they can figure out how to use a GUI by trial and error. I would introduce them to the customizability not available on Windows with being able to choose Gnome, KDE, Unity, Avant Window Navigator, etc. Also little niceties like middle click pasting, multiple desktops, and focus follows mouse that they may have never seen.
Since they are CS students, I would also cover the basics of developing on Linux that may be unfamiliar:
Basically, cover enough so when a professor gives them a programming assignment in subsequent semesters, they should be able to focus on the code more than the operating system. A typical assignment toward the end of the class would reflect mastery of the development environment but require little programming expertise, something like "create a .deb package containing a program that displays hello world in a Gtk window" or "submit a git bundle with a change from hello world to hey there world."
Are you kidding? Debt is transferred all the time. Have you never sold a savings bond?
Also, sovereign debt isn't revolving like a credit card. It has fixed terms and needs to be refinanced all the time. Just China stopping buying new debt would have significant repercussions.
It already is, for very liberal definitions of "integrated." :-)
Zero day refers to how much time an administrator has to patch his systems before an exploit is known. Since this is still not patched, it is indeed a zero day exploit, although if the exploit is as yet unused it is not a zero day attack.
I completely agree about needing a basic understanding of reading and writing math first. I haven't seen the inside of a math classroom in many years, and my work doesn't involve a lot of "heavy" math, but I use basic algebra at work fairly regularly. Recently, an acquaintance of mine in a college algebra class commented that she understood most of the class really well except for the "word problems." I hadn't heard that phrase in so long that I had forgotten it existed. All the math I do is "word problems" and it is utterly useless to me otherwise. It astounded me that someone could consider themselves good at math when they didn't even have the basic skill of being able to transcribe back and forth between math and english.
Probably because they never took that class. I can imagine management saying, "This one doesn't have a light, so we don't need electrical engineering to approve the design, only mechanical." That sort of thing happens at my work more often than I would expect, going both ways.
Um, no.
At her insistence, a blue e opened my wife's web browser for a year or so after we switched to Linux. That was pre-firefox, I think it was just plain mozilla suite web browser.
Last week, she bought some sort of device to make Skype calls from our regular phone and manually installed the device driver and userspace daemon, all without my input at all. I couldn't be more proud :-)
Is that for results that all start with the same sound?
Unless you're foregoing those items altogether, you're probably not saving any money. Testers have significantly lower salaries than programmers. When a programmer does all the testing, you are paying programmer rates for testing work.
You're both missing the point here. Knowing the current commute time is fairly easy. The tricky part is using the measurements now to predict the commute times an hour from now. My commute ranges from 20 up to 50 minutes or so. If I can look on a website and see in a half hour my commute will be a half hour shorter, I'll just wait. If it's still going to be long, I'd rather slog it out now and get it over with.
I hate to break it to you, but even if your trunk is clean, you will still have this problem in some other branch. Let's examine a very common situation where you have an interface being changed, one or more implementations of that interface, and one or more users of that interface. Developers are working simultaneously on both sides of that interface in order to meet a deadline.
Because of your clean trunk rule, none of the changes can be checked into the trunk until all of the changes are ready, but they still need to be shared among the people working on it, or they will have no idea if it is "good and ready." So those developers create their own branch, which of necessity is sometimes in a temporarily broken state. You might not think of it as a branch, if it's John's working directory and the "checkout" procedure is him emailing files around, but it's conceptually a branch nonetheless.
Linus is simply acknowledging that temporary brokenness is inevitable when multiple people integrate changes to the same code, and therefore whatever branch contains that messy integration should use tags to communicate the best branch points. I'm not saying keeping a clean trunk isn't a good idea, just that you have to deal with broken branch points one way or another, even if it's just John deciding when the best time is to email out the new header files to his team.
I know, we could just set the punishment for distracted driving really high. Let's say the death penalty by means of fiery crash.
True, but irrelevant. Climbing on the roof is still better for the individual at the expense of the system. Just because behavior is accepted and accounted for doesn't make it optimal.
I make a living writing embedded software for telecommunications equipment and am also a ham radio operator, so I have a hard time seeing why this isn't blindingly obvious to everyone, but if you want more wireless bandwidth and less congestion, each individual's signal must have the lowest power necessary for reliable communication.
For example, say you have 100 cell phones in active use at any given time in your neighborhood. If every cell phone signal in that neighborhood is boosted to be able to cover the entire neighborhood, each subscriber necessarily is limited to 1% of the available wireless bandwidth for that neighborhood. If you limit each signal to the walls of a person's home, every individual gets 100 times more bandwidth because they aren't competing with their neighbors. You can always lay more fiber to increase bandwidth. Increased wireless bandwidth is only possible by limited technological improvements. That's an over-simplification, but you get my point.
Boosting an individual's signal may be temporarily good for that individual, but bad for the system. There are alternatives that are good for both the individual and the system. Hence, the desire for regulation.
Yeah, I remember those classes. I spent so much time trying to write really small that I accidentally learned the material.
You're right. That's much less pointless than just plugging the hotplate into the outlet the PSU is plugged into.
That's my favorite part about these sorts of laws. The death penalty doesn't deter them, but people think a small fine will.
That's because people who don't know what they are doing don't know that they don't know what they're doing. Those types of comments should be accompanied by a clear competence or acceptance test. For example, the last such comment I wrote went something like: /* This might look like an unnecessary delay, but the timing has been carefully calibrated against a wide range of marginal real world conditions. If you touch this function, you must ensure it does not time out under these configurations... */
In other words, "knowing what you're doing" must be definable and transferable knowledge.
I had thought it was part of the same process in Ubuntu that prompts to install other proprietary drivers like nvidia, but maybe it's a future plan I remember reading. The last time I did it myself was 3 years ago. Starting up ndisgtk and browsing to the .inf file is more than one click, but I'd hardly call it "messing with configs."