Asserting rights isn't the problem. It's doing so in a way that doesn't infringe on others' rights. The precise circumstances of what rights are most important in what situations is the result of centuries of legal precedent. You can either do that research yourself, or hire a lawyer.
I'm not the AC, but I share his sentiment. Please define obscene, and then explain why you chose that definition.
You're seeking the advice of someone whose job involves years of study and continuous certification, and probably a team of highly-skilled experts to assist. What exactly is a reasonable rate for their time?
Because that furthers the narrative that Bitcoins are a disruptive anti-entablishment technology that will free us from the oppressive tyranny of government, so that's what Bitcoin-loving sites like Slashdot will emphasize.
Really, it's because the authorities are going after anyone who is breaking the law. The Bitcoin creator is believed to have a few hundred million dollars' worth of coins, and converting that to a taxable asset without paying taxes is one form of unlawful tax evasion. If someone legitimately deals in large quantities of commodity goods, they should be maintaining a complete record of every transaction made with that commodity, and paying taxes appropriately.
For practical purposes, all of Earth has a neutral nitrogen and oxygen atmosphere between 0 and 50 degrees Celsius, with precipitation of water, and winds generally under 15m/s.
If you're planning a pit stop in this solar system, and your choices are between the acid atmosphere of Venus, the hull-threatening storms of Jupiter, or Earth, you probably don't care about such small variations.
If your species routinely makes such stops, you're probably either biologically or technologically capable of handling a wider variety of climates than mere fragile humans.
If this particular stop is routine, and doesn't require any special treatment, why bother mentioning the climate in the narrative?
As I described, most communication would require only four words, and those words have far less entropy that the word list used in this scheme. If I'm conversing with someone and giving them a location near me, assumptions can be made about any unspecified information. For example, if we assume that the location is in the same quadrant of the city, I only need to convey two numbers, and because they aren't hashes, even an approximate match will likely result in success.
We must also consider the nature of the numbers themselves, and human cognition. We're pretty good at remembering things, but pretty poor at remembering them accurately. Rather, we remember the connections between our memories. If someone tells me, for instance, that their location is "127, 64", I'll remember that by noting the connection to the powers of two that I already have well-memorized. On the other hand, "brass.apple.chimpanzee" has a good chance of being connected to "metal.fruit.monkey", and I'll end up trying to locate "tin.banana.gorilla". The word lists could be constructed to minimize the risk of such a cognitive hash collision, but with 40,000 words across 10 languages and being run through 4 billion memories, a small risk is still a high number of error.
Compounding that cognitive problem is the convenience of the system. If I'm talking on the phone with someone arranging a meeting, and I'm given a numeric location, I can mentally start working out roughly where that location is. It may not be close enough for navigating, but I can estimate the rough area of my destination. That serves as an error-correcting checksum on my memory that not only indicates that I've misremembered the location, but can be used to validate alternatives (like transposing numbers or coordinates). When I then use a GPS tool or dead-reckoning to navigate, I can be assured of the device's correct functioning as well as the integrity of my location information.
Of course, it's easy for us Slashdotters to assume the presence of cheap electronics... but this word-based system is being touted for use in extremely impoverished areas. These are places where long-term planning is irrelevant if one does not find the money for short-term needs. These are places where "building a home" consists of putting some garbage on the ground before sleeping. In those places, any electronics, even dumb-phones often get stolen and re-sold to wealthier folks (who usually have conventional addresses) for a few meals' worth of money.
Words are easy for humans to remember, but they're awful for processing, which is why most of the world switched to numbers a long time ago. Many European cities used to use house names when there were only a few hundred houses in the area, then they switched to using street names and numbers when it became too difficult to keep track of everyone's movements.
Using coordinates allows you to estimate distances just by knowing two locations. You can use them for direct-path navigation, as well as (except for extreme latitudes) travel constrained to cardinal directions, as most large cities tend to support. Given a location, you can also know roughly where you're going without the aid of any electronic device, and with some experience, one can get quite skilled at figuring out their location by only dead-reckoning.
This scheme provides what is effectively a hash of each location on the globe. That's wonderfully useful for determining "am I here?", but not very good for figuring out "how do I get there?". To effectively navigate, the three-word addresses must be translated into coordinates anyway, then compared to a graph of potential routes, and a path derived from that. Effectively, it's just an extra step (which requires a computer's help, or a book of lookup tables) for anyone trying to find a particular location.
A more useful scheme would be to divide the world into regions and subregions, using easily-memorized or safely-assumed names. Then divide those large areas into small blocks, and give them numeric addresses, which can be subdivided as necessary to reach any level of precision. For example, the Central City Recreation Center is located in the nation of "United States of America", in the region "Utah", subregion "Salt Lake City", at a grid location of "615 South 300 East". It pretty much covers the area from 600 South 300 East to 640 South 350 East, so if you really needed to specify a particular 9-square-meter room, you have a reasonable way to do it with the existing system. Having only visited Salt Lake City once, I can tell you that it's not too far from City Hall, which is centered around 450 South 150 East.
You use cones to create a temporary lane division to control traffic flow.
It's a two-lane road (one each way) already. Creating a temporary division is not possible. What is possible is for drivers to follow the law and go slow enough that they can stop for obstacles in the road.
A sensible city code also includes requirements for lines of sight, etc., when points of ingress and egress to/from the property are permitted, to prevent creating situations like that one.
And in situations where legislation can't change the physical reality, it requires warning signs and slower speeds, both of which are in effect already.
The simple answer is for drivers to obey the law. Those that don't get the punishment set forth in the statute, which reflects the same hardship their careless actions cast on the rest of society, including lowly stagehands.
That would be the cheapest and easiest solution: put out some cones and a sign for traffic control at that time.
If a driver isn't paying attention to speed limits, existing warning signs, or a man standing by the road in a bright yellow vest and waving bright orange flags, what makes you think they'll pay attention to a few cones?
Public safety is more important than public access to movie theaters.
Actually, the law already says that public safety is more important than a driver's need to get somewhere a few seconds faster. That's why the speed limit exists in the first place.
I worked at a theater. We had pedestrian crowds at midday and at midnight. My post was actually usually guiding trucks out the back, which put me standing just around a blind corner on the road.
Are you suggesting that we barricade the road before every performance ends? Should we redesign the city's roads to allow a few trucks to pull out easily each week? Or maybe, just maybe, drivers should be aware that they're operating a machine that can easily kill or maim people with only a moment's notice.
The OP said nothing about flat fines. Rather, he mentioned a minimum that imposes a hardship on someone with low income, and complains that the fine and associated fees should be lower. I'm suggesting that the total cost should be weighed against the health of another human being.
In some jurisdictions, including the one where I worked, judges already have the (seldom-used) ability to raise the fine to meet the goals of fairness, retribution, and rehabilitation. I do think that should be utilized more, but that's a different matter.
I used to work nights on a road directing traffic. Every time I put on the reflective vest, I got to see the blood stain from my predecessor who got hit when someone didn't think they really needed to heed the warning signs.
Yes, a speeding fine in an area where pedestrians are present should make your life hell for a while. You're risking someone else's life for the sake of getting to your destination a few seconds earlier. You don't get that right, regardless of how high or low your income is.
From what I see on the Marshals' listings, the items being sold are forfeited pursuant to a final judgement from a suitable court. The proceeds are indeed listed as part of the judgement, and would therefore be distributed among the victims (possibly including the government itself) as any similar fine would.
Some jurisdictions may be abusing forfeiture for profit - and that's bad - but it's quite a leap to extrapolate that to all law enforcement agencies in the country, as some Slashdotters are quick to do.
Now, I (thankfully) haven't worked with BlackBerry products in many years, and I had hoped/expected that things had changed, but pretty much all phone data used to be stored on company-managed servers. The government wouldn't have direct access, but corporate IT staff would.
From the little information in TFS, it sounds like the phones are not the vulnerability, but a central server under corporate control would be a suitable target for court-ordered surveillance. That way, the corporation can avoid the hassle of being found in contempt of court.
There's some secrets acts and probably a case to be made for being a traitor (albeit a weak case - but one the State could try)
Those are exactly the laws that Snowden has openly admitted to breaking. It's a pretty strong case by all (informed) accounts.
Jury nullification relies on a sympathetic and intelligence populace.
Jury nullification of law relies on a population that thinks situational ethics are a better justice system than rule of law. In essence, it is throwing out the entire legal basis of a fair trial in favor of mob justice for a celebrity - for better or for worse.
Most US laws that define a particular behavior as a "crime" also define particular circumstances in which the behavior is an exception to the rule. A defense in a trial is really just arguing to a judge that the exception applies to your particular case, rather than the general rule, or arguing to a jury that your circumstances don't fit the exact detail of the criminal statute. Despite common perception, the intent of a trial is not to decide whether some action should be a crime, but to determine whether the crime has already occurred.
Unfortunately for Mr. Snowden's fans, he's already said openly to the world that he did exactly what the law forbids. He intentionally exceeded his authority to collect classified information, and released it to people who weren't authorized to have it. As far as I understand the relevant laws, there are no exceptions to that crime.
If you support Snowden and want him to return to his normal life without punishment for whatever crimes he's committed, your best hope is probably that he gets a very sympathetic judge, who would accept an argument that his noble intent is superior to the written laws governing the handling of classified material. That's pretty literally "legislating from the bench", and it would establish a very broad defense for future treason.
Perhaps more reasonable, though less likely in my opinion, is the pursuit of a pardon, as Aighearach noted. The President's office would have to be convinced that Snowden's actions were not deserving of punishment, regardless of what the law or courts say. Snowden would still be a convicted felon, but most of the punishment would be removed. However, a pardon would have to be pursued after a conviction, and I expect that Snowden would rather be a martyr in exile than face a proper American trial.
You can illustrate the concepts with any language, but usually not nearly as well.
It is not enough to merely show someone a concept in use. They must see only that concept to be able to learn it. It's not as effective to mix variables in with namespaces, class definitions, library imports, or namespaces. Students will often focus on the boilerplate that they're not expected to understand yet, and miss the fundamental concepts that the lesson is supposed to be teaching. It's that simplicity that makes BASIC ideal.
Sure, other languages can be that simple, but usually they simply choose not to be. Rather, language creators want to market their creations as solutions to the much-discussed STEM crisis, so the language has to support all of the latest ideas. That often means adding boilerplate declarations, by which the students will happily be distracted.
I've long been an advocate of using BASIC (or a more forgiving variant) for the first two weeks of a programming curriculum......and no more.
To use the analogy of TFS, BASIC has big text, and is useful for illustrating the alphabet of programming. Students should understand a few key concepts from the exercise, the misunderstanding of which often leads to difficulty following later classes.
I've seen countless students who missed the core concepts that statements run in order (some language exceptions apply), variables change, and that every step of the process has to be listed.
Frankly, I think those concepts are more important than learning how to build a class or compile a binary. BASIC was a good place to start.
Do you also consider people who pig out at buffets to be Food Hogs?
You mean those all-you-can-eat buffets that throttle you by requiring food go in your mouth rather than a take-out container, and then put a cap on kicking you out at closing time?
Yeah, I just get so angry at those places. They advertised all I could eat, then they want to apply reason to the deal after I'm in the door!
Where do you draw the line? 5G? 10G? 15G? 23G?
You put it somewhere reasonable, where the burden on the customer is not unjust, and the burden on the provider isn't unjust, either. Expecting the provider to support huge amounts of data transfer to every customer in a cell is unreasonable, and it's also unreasonable to throttle "unlimited" customers unnecessarily. Realistically, providers get to set limits wherever they want, and customers get to sue to have a court figure out what's reasonable.
That's what I have from T-Mobile now... but surprisingly T-Mobile actually sells it as a 10G plan.
As a fellow T-Mobile customer, no, it's not. T-Mobile actually makes a big deal about advertising their unlimited service, only occasionally mentioning that it's throttled down to 3G speeds after some paid-for package amount. Their sales reps and detailed documents do make it clear that's how it works, but their big billboard ads are just as bad as anybody else.
Once upon a time, if something failed, you booted in single-user mode.
...which means yet another reboot, which may or may not replicate the problem and allow debugging.
And you got a shell, not the "One True and Non-Replaceable Shell". Systemd takes away the flexibility to configure things optimally for your specific needs.
Per the documentation, the "login shell" that everyone complains about is just a controller command that runs/bin/sh by default, or any other command presented.
If systemd offered plug-in loggers and one of them happened to be a binary log database, that would be OK. But systemd's designers apparently lack the skills to make a simple and flexible system.
Also per documentation, the default journal is not the only option. You can also send output to syslog, kmsg, the console, or a socket.
Can't comment. I haven't had much to do with anything beyond the man pages.
Clearly you haven't bothered to read those much, either.
Well, in this case, it's that there was no "trial mode" for people to gradually evaluate, find bugs in, and accept/reject. Instead all of the sudden the familiar, functional (if imperfect) systems were all gone and systemd ruled everything. Since systemd isn't as flexible as what it replaced, you couldn't fall back to the old stuff in cases where it failed to satisfy or as an emergency solution.
Systemd was apparently around for a year before the first distro adopted it. There's been plenty of time to review and comment, but so far all of the discussion seems to be just criticism by folks who clearly haven't bothered to read the documentation for the things they complain about.
OK. But the rate at which you "close bugs" is a meaningless metric. Were the bugs closed because repairs had been made or were they simply marked "WONTFIX"?
Again, that's no different from any other software project.
If your system is so fragile that a single server being down is that critical, maybe you need to re-evaluate your architecture.
I never said it was fragile. I said that it must be 100% operational. I work on a very particular kind of high-end processing system, running a few dozen specialized servers. There's an array of video processors, a separate array of audio processors, a number of systems just for I/O, and a small (by the vendor's standards) HPC system. Some of it runs Linux, some runs Windows, and the whole thing has to be able to be brought online in 15 minutes.
Again, you don't get to assume what my requirements are.
For those of us to whom such things are essential, we have clusters, failovers, and other HA constructs so that the loss of a single machine doesn't hold the whole operation prisoner.
All of those options are expensive, and require additional infrastructure and upkeep, as well as additional engineering to make it all work in the first place. It also increases the price tag on every system we build.
Yes, faster boot times are nice, but even at its worst, a Linux system boots significantly faster than Windows. You don't have the machine being thrashed by massive software updates and disk-burning virus checks on reboot.
Instead the system waits for fsck every month, refuses to move until it's tried to initialize every NIC on the system, won't start X until the sound system is ready, and let's not even discuss the wait if a NFS mount is unavailable. Yes, you can also install a virus scanner or configure your system to look for updates at every boot.
The real problem is serialized startup. If systemd makes it easier to run things in parallel, that's a good thing. Upstart did well for that, too.
I concur with the AC above me who justifies most of those, but I'll add my own opinions as well.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
...Because it should. When the system's done initializing, I want a logon shell available. If something fails, I want a shell as a fallback. I also have a particular application where I need authentication before allowing the system to begin its automatic operations, but after certain services have started. Maybe this will help that, but I haven't explored the design enough to know.
As for DHCP, it's about time. DHCP has been a part of initrd and init scripts for many years, often with lots of implementation-specific bugs. It stems from Unix's history as an OS predating networks, and now DHCP is an add-on to most systems, where it was designed to be a central configuration mechanism (including options for pushing NTP, IRC, LDAP, and even time zone information from the server). By coincidence, a lot of my academic research and professional work involves centralized self-configuring systems, so seeing hope for DHCP is actually a very good thing, by my standards. I'd love to see computers stop duplicating configuration settings.
Binary log files (PUKE)
...which are really the first step towards a proper database holding log files, which I'd also love to see someday. Windows has its event service, which uses binary logs to fairly good effect, though it can get very slow for sorting and searching. A proper database is much better for that sort of thing, but I digress. As I understand, the binary format is trying to avoid being a full database, while still supporting filtering. It also seems to do a fairly decent job of separating user and system logs, and would allow filtering a single service or seeing the whole system's logs, without the current hassle of dealing with applications that don't properly declare who they are when logging.
Extremely poor documentation
This seems pretty subjective to me, so you'll need to do better for a complaint. When I've had to look up systemd documentation, it's been no worse (or much better) than any other GNU/Linux documentation.
Rushed to market with little objective testing
What, exactly, is "objective" testing for a completely different software architecture? The software managers I work with have been debating the essence of that question for the past few decades. That said, it's been out for five years. It is in active use, and working well enough for all normal purposes.
Bugs pile up with no resolution in sight, they just keep going for another dameon.
...So it's like any other software project? New development is usually the priority once something works well enough. I'll also note that within the last month, 60 bug reports have been closed on systemd's github tracker, and only 44 opened. The oldest bug is from June.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless.
No, you don't reboot servers, so your boot time is meaningless, but you have no justification to project that onto me. I actually work on a system with a requirement to cold-start the entire site in 15 minutes, from turning on the circuit breaker to being 100% ready for operation. My boot time is very meaningful.
As a sysadmin, I think it's to make my life miserable. As a user, I think it's because nobody gives a damn about logs for a system that's working.
After a quick search for the relevant document, it seems the default for stderr is to inherit settings, presumably from some kind of hierarchy that I don't know enough about to comment on. By default, then, I'd guess the top level discards logs.
From an architecture standpoint, that makes sense. On my work-related systems, I could just configure the top level, and get logs everywhere, or configure it for only the services that my system actually cares about. On the nearly-a-kiosk preconfigured laptop I gave to my mother, I don't need it to waste time or disk space recording logs that nobody will ever read. If I have to troubleshoot the machine, I'll turn on logging then.
it happened over your continual vociferous objections
That's exactly the problem.
I have a dog in this fight. I'm a sysadmin, who often gets involved in engineering Linux-based systems. My top priority is that everything works reliably when I need it. I don't really care what style of startup scripts we use. If it's something I already know, that makes life easier in some ways, but I'm not so arrogant as to assume that a better way isn't possible. If that new system's better just because I know that somebody's reviewed their assumptions in the last decade, that alone is worth a bit.
Then there's Slashdot. While most rational discussions about systemd tend to discuss pros and cons, Slashdot's hivemind seems to have decided that systemd is simply evil, with no clear reason why. I understand that we're all traditionalists, but this often goes beyond common sense. As you've noted, the arguments are loud, repetitive, and vehement, and they've been going on for longer than I care to remember. There are no suggestions for improvement, other than to fork huge projects and insist that nothing can ever change.
Frankly, the objections are a bit old. They're often just reiterating rumors and outdated information, and contribute nothing to the conversation. I expect the developers have heard the objections, and either resolved the complaints or chosen intentionally to take a different path. As a community, can we please now move on to the next topic of discussion?
Slashdot Mirror
Asserting rights isn't the problem. It's doing so in a way that doesn't infringe on others' rights. The precise circumstances of what rights are most important in what situations is the result of centuries of legal precedent. You can either do that research yourself, or hire a lawyer.
I'm not the AC, but I share his sentiment. Please define obscene, and then explain why you chose that definition.
You're seeking the advice of someone whose job involves years of study and continuous certification, and probably a team of highly-skilled experts to assist. What exactly is a reasonable rate for their time?
Because that furthers the narrative that Bitcoins are a disruptive anti-entablishment technology that will free us from the oppressive tyranny of government, so that's what Bitcoin-loving sites like Slashdot will emphasize.
Really, it's because the authorities are going after anyone who is breaking the law. The Bitcoin creator is believed to have a few hundred million dollars' worth of coins, and converting that to a taxable asset without paying taxes is one form of unlawful tax evasion. If someone legitimately deals in large quantities of commodity goods, they should be maintaining a complete record of every transaction made with that commodity, and paying taxes appropriately.
For practical purposes, all of Earth has a neutral nitrogen and oxygen atmosphere between 0 and 50 degrees Celsius, with precipitation of water, and winds generally under 15m/s.
If you're planning a pit stop in this solar system, and your choices are between the acid atmosphere of Venus, the hull-threatening storms of Jupiter, or Earth, you probably don't care about such small variations.
If your species routinely makes such stops, you're probably either biologically or technologically capable of handling a wider variety of climates than mere fragile humans.
If this particular stop is routine, and doesn't require any special treatment, why bother mentioning the climate in the narrative?
As I described, most communication would require only four words, and those words have far less entropy that the word list used in this scheme. If I'm conversing with someone and giving them a location near me, assumptions can be made about any unspecified information. For example, if we assume that the location is in the same quadrant of the city, I only need to convey two numbers, and because they aren't hashes, even an approximate match will likely result in success.
We must also consider the nature of the numbers themselves, and human cognition. We're pretty good at remembering things, but pretty poor at remembering them accurately. Rather, we remember the connections between our memories. If someone tells me, for instance, that their location is "127, 64", I'll remember that by noting the connection to the powers of two that I already have well-memorized. On the other hand, "brass.apple.chimpanzee" has a good chance of being connected to "metal.fruit.monkey", and I'll end up trying to locate "tin.banana.gorilla". The word lists could be constructed to minimize the risk of such a cognitive hash collision, but with 40,000 words across 10 languages and being run through 4 billion memories, a small risk is still a high number of error.
Compounding that cognitive problem is the convenience of the system. If I'm talking on the phone with someone arranging a meeting, and I'm given a numeric location, I can mentally start working out roughly where that location is. It may not be close enough for navigating, but I can estimate the rough area of my destination. That serves as an error-correcting checksum on my memory that not only indicates that I've misremembered the location, but can be used to validate alternatives (like transposing numbers or coordinates). When I then use a GPS tool or dead-reckoning to navigate, I can be assured of the device's correct functioning as well as the integrity of my location information.
Of course, it's easy for us Slashdotters to assume the presence of cheap electronics... but this word-based system is being touted for use in extremely impoverished areas. These are places where long-term planning is irrelevant if one does not find the money for short-term needs. These are places where "building a home" consists of putting some garbage on the ground before sleeping. In those places, any electronics, even dumb-phones often get stolen and re-sold to wealthier folks (who usually have conventional addresses) for a few meals' worth of money.
Words are easy for humans to remember, but they're awful for processing, which is why most of the world switched to numbers a long time ago. Many European cities used to use house names when there were only a few hundred houses in the area, then they switched to using street names and numbers when it became too difficult to keep track of everyone's movements.
Using coordinates allows you to estimate distances just by knowing two locations. You can use them for direct-path navigation, as well as (except for extreme latitudes) travel constrained to cardinal directions, as most large cities tend to support. Given a location, you can also know roughly where you're going without the aid of any electronic device, and with some experience, one can get quite skilled at figuring out their location by only dead-reckoning.
This scheme provides what is effectively a hash of each location on the globe. That's wonderfully useful for determining "am I here?", but not very good for figuring out "how do I get there?". To effectively navigate, the three-word addresses must be translated into coordinates anyway, then compared to a graph of potential routes, and a path derived from that. Effectively, it's just an extra step (which requires a computer's help, or a book of lookup tables) for anyone trying to find a particular location.
A more useful scheme would be to divide the world into regions and subregions, using easily-memorized or safely-assumed names. Then divide those large areas into small blocks, and give them numeric addresses, which can be subdivided as necessary to reach any level of precision. For example, the Central City Recreation Center is located in the nation of "United States of America", in the region "Utah", subregion "Salt Lake City", at a grid location of "615 South 300 East". It pretty much covers the area from 600 South 300 East to 640 South 350 East, so if you really needed to specify a particular 9-square-meter room, you have a reasonable way to do it with the existing system. Having only visited Salt Lake City once, I can tell you that it's not too far from City Hall, which is centered around 450 South 150 East.
You use cones to create a temporary lane division to control traffic flow.
It's a two-lane road (one each way) already. Creating a temporary division is not possible. What is possible is for drivers to follow the law and go slow enough that they can stop for obstacles in the road.
A sensible city code also includes requirements for lines of sight, etc., when points of ingress and egress to/from the property are permitted, to prevent creating situations like that one.
And in situations where legislation can't change the physical reality, it requires warning signs and slower speeds, both of which are in effect already.
The simple answer is for drivers to obey the law. Those that don't get the punishment set forth in the statute, which reflects the same hardship their careless actions cast on the rest of society, including lowly stagehands.
That would be the cheapest and easiest solution: put out some cones and a sign for traffic control at that time.
If a driver isn't paying attention to speed limits, existing warning signs, or a man standing by the road in a bright yellow vest and waving bright orange flags, what makes you think they'll pay attention to a few cones?
Public safety is more important than public access to movie theaters.
Actually, the law already says that public safety is more important than a driver's need to get somewhere a few seconds faster. That's why the speed limit exists in the first place.
I worked at a theater. We had pedestrian crowds at midday and at midnight. My post was actually usually guiding trucks out the back, which put me standing just around a blind corner on the road.
Are you suggesting that we barricade the road before every performance ends? Should we redesign the city's roads to allow a few trucks to pull out easily each week? Or maybe, just maybe, drivers should be aware that they're operating a machine that can easily kill or maim people with only a moment's notice.
The OP said nothing about flat fines. Rather, he mentioned a minimum that imposes a hardship on someone with low income, and complains that the fine and associated fees should be lower. I'm suggesting that the total cost should be weighed against the health of another human being.
In some jurisdictions, including the one where I worked, judges already have the (seldom-used) ability to raise the fine to meet the goals of fairness, retribution, and rehabilitation. I do think that should be utilized more, but that's a different matter.
I used to work nights on a road directing traffic. Every time I put on the reflective vest, I got to see the blood stain from my predecessor who got hit when someone didn't think they really needed to heed the warning signs.
Yes, a speeding fine in an area where pedestrians are present should make your life hell for a while. You're risking someone else's life for the sake of getting to your destination a few seconds earlier. You don't get that right, regardless of how high or low your income is.
From what I see on the Marshals' listings, the items being sold are forfeited pursuant to a final judgement from a suitable court. The proceeds are indeed listed as part of the judgement, and would therefore be distributed among the victims (possibly including the government itself) as any similar fine would.
Some jurisdictions may be abusing forfeiture for profit - and that's bad - but it's quite a leap to extrapolate that to all law enforcement agencies in the country, as some Slashdotters are quick to do.
Sarcasm aside, that's pretty much the goal, yes.
Now, I (thankfully) haven't worked with BlackBerry products in many years, and I had hoped/expected that things had changed, but pretty much all phone data used to be stored on company-managed servers. The government wouldn't have direct access, but corporate IT staff would.
From the little information in TFS, it sounds like the phones are not the vulnerability, but a central server under corporate control would be a suitable target for court-ordered surveillance. That way, the corporation can avoid the hassle of being found in contempt of court.
However, that's what jury nullification is for.
No, it isn't.
There's some secrets acts and probably a case to be made for being a traitor (albeit a weak case - but one the State could try)
Those are exactly the laws that Snowden has openly admitted to breaking. It's a pretty strong case by all (informed) accounts.
Jury nullification relies on a sympathetic and intelligence populace.
Jury nullification of law relies on a population that thinks situational ethics are a better justice system than rule of law. In essence, it is throwing out the entire legal basis of a fair trial in favor of mob justice for a celebrity - for better or for worse.
Probably not.
Most US laws that define a particular behavior as a "crime" also define particular circumstances in which the behavior is an exception to the rule. A defense in a trial is really just arguing to a judge that the exception applies to your particular case, rather than the general rule, or arguing to a jury that your circumstances don't fit the exact detail of the criminal statute. Despite common perception, the intent of a trial is not to decide whether some action should be a crime, but to determine whether the crime has already occurred.
Unfortunately for Mr. Snowden's fans, he's already said openly to the world that he did exactly what the law forbids. He intentionally exceeded his authority to collect classified information, and released it to people who weren't authorized to have it. As far as I understand the relevant laws, there are no exceptions to that crime.
If you support Snowden and want him to return to his normal life without punishment for whatever crimes he's committed, your best hope is probably that he gets a very sympathetic judge, who would accept an argument that his noble intent is superior to the written laws governing the handling of classified material. That's pretty literally "legislating from the bench", and it would establish a very broad defense for future treason.
Perhaps more reasonable, though less likely in my opinion, is the pursuit of a pardon, as Aighearach noted. The President's office would have to be convinced that Snowden's actions were not deserving of punishment, regardless of what the law or courts say. Snowden would still be a convicted felon, but most of the punishment would be removed. However, a pardon would have to be pursued after a conviction, and I expect that Snowden would rather be a martyr in exile than face a proper American trial.
If anything imperfect happens, it is obviously the result of nefarious government interference.
So sayeth the hivemind.
You can illustrate the concepts with any language, but usually not nearly as well.
It is not enough to merely show someone a concept in use. They must see only that concept to be able to learn it. It's not as effective to mix variables in with namespaces, class definitions, library imports, or namespaces. Students will often focus on the boilerplate that they're not expected to understand yet, and miss the fundamental concepts that the lesson is supposed to be teaching. It's that simplicity that makes BASIC ideal.
Sure, other languages can be that simple, but usually they simply choose not to be. Rather, language creators want to market their creations as solutions to the much-discussed STEM crisis, so the language has to support all of the latest ideas. That often means adding boilerplate declarations, by which the students will happily be distracted.
That is indeed the point that is often forgotten.
I've long been an advocate of using BASIC (or a more forgiving variant) for the first two weeks of a programming curriculum... ...and no more.
To use the analogy of TFS, BASIC has big text, and is useful for illustrating the alphabet of programming. Students should understand a few key concepts from the exercise, the misunderstanding of which often leads to difficulty following later classes.
I've seen countless students who missed the core concepts that statements run in order (some language exceptions apply), variables change, and that every step of the process has to be listed.
Frankly, I think those concepts are more important than learning how to build a class or compile a binary. BASIC was a good place to start.
Do you also consider people who pig out at buffets to be Food Hogs?
You mean those all-you-can-eat buffets that throttle you by requiring food go in your mouth rather than a take-out container, and then put a cap on kicking you out at closing time?
Yeah, I just get so angry at those places. They advertised all I could eat, then they want to apply reason to the deal after I'm in the door!
Where do you draw the line? 5G? 10G? 15G? 23G?
You put it somewhere reasonable, where the burden on the customer is not unjust, and the burden on the provider isn't unjust, either. Expecting the provider to support huge amounts of data transfer to every customer in a cell is unreasonable, and it's also unreasonable to throttle "unlimited" customers unnecessarily. Realistically, providers get to set limits wherever they want, and customers get to sue to have a court figure out what's reasonable.
That's what I have from T-Mobile now ... but surprisingly T-Mobile actually sells it as a 10G plan.
As a fellow T-Mobile customer, no, it's not. T-Mobile actually makes a big deal about advertising their unlimited service, only occasionally mentioning that it's throttled down to 3G speeds after some paid-for package amount. Their sales reps and detailed documents do make it clear that's how it works, but their big billboard ads are just as bad as anybody else.
Once upon a time, if something failed, you booted in single-user mode.
...which means yet another reboot, which may or may not replicate the problem and allow debugging.
And you got a shell, not the "One True and Non-Replaceable Shell". Systemd takes away the flexibility to configure things optimally for your specific needs.
Per the documentation, the "login shell" that everyone complains about is just a controller command that runs /bin/sh by default, or any other command presented.
If systemd offered plug-in loggers and one of them happened to be a binary log database, that would be OK. But systemd's designers apparently lack the skills to make a simple and flexible system.
Also per documentation, the default journal is not the only option. You can also send output to syslog, kmsg, the console, or a socket.
Can't comment. I haven't had much to do with anything beyond the man pages.
Clearly you haven't bothered to read those much, either.
Well, in this case, it's that there was no "trial mode" for people to gradually evaluate, find bugs in, and accept/reject. Instead all of the sudden the familiar, functional (if imperfect) systems were all gone and systemd ruled everything. Since systemd isn't as flexible as what it replaced, you couldn't fall back to the old stuff in cases where it failed to satisfy or as an emergency solution.
Systemd was apparently around for a year before the first distro adopted it. There's been plenty of time to review and comment, but so far all of the discussion seems to be just criticism by folks who clearly haven't bothered to read the documentation for the things they complain about.
OK. But the rate at which you "close bugs" is a meaningless metric. Were the bugs closed because repairs had been made or were they simply marked "WONTFIX"?
Again, that's no different from any other software project.
If your system is so fragile that a single server being down is that critical, maybe you need to re-evaluate your architecture.
I never said it was fragile. I said that it must be 100% operational. I work on a very particular kind of high-end processing system, running a few dozen specialized servers. There's an array of video processors, a separate array of audio processors, a number of systems just for I/O, and a small (by the vendor's standards) HPC system. Some of it runs Linux, some runs Windows, and the whole thing has to be able to be brought online in 15 minutes.
Again, you don't get to assume what my requirements are.
For those of us to whom such things are essential, we have clusters, failovers, and other HA constructs so that the loss of a single machine doesn't hold the whole operation prisoner.
All of those options are expensive, and require additional infrastructure and upkeep, as well as additional engineering to make it all work in the first place. It also increases the price tag on every system we build.
Yes, faster boot times are nice, but even at its worst, a Linux system boots significantly faster than Windows. You don't have the machine being thrashed by massive software updates and disk-burning virus checks on reboot.
Instead the system waits for fsck every month, refuses to move until it's tried to initialize every NIC on the system, won't start X until the sound system is ready, and let's not even discuss the wait if a NFS mount is unavailable. Yes, you can also install a virus scanner or configure your system to look for updates at every boot.
The real problem is serialized startup. If systemd makes it easier to run things in parallel, that's a good thing. Upstart did well for that, too.
I concur with the AC above me who justifies most of those, but I'll add my own opinions as well.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
...Because it should. When the system's done initializing, I want a logon shell available. If something fails, I want a shell as a fallback. I also have a particular application where I need authentication before allowing the system to begin its automatic operations, but after certain services have started. Maybe this will help that, but I haven't explored the design enough to know.
As for DHCP, it's about time. DHCP has been a part of initrd and init scripts for many years, often with lots of implementation-specific bugs. It stems from Unix's history as an OS predating networks, and now DHCP is an add-on to most systems, where it was designed to be a central configuration mechanism (including options for pushing NTP, IRC, LDAP, and even time zone information from the server). By coincidence, a lot of my academic research and professional work involves centralized self-configuring systems, so seeing hope for DHCP is actually a very good thing, by my standards. I'd love to see computers stop duplicating configuration settings.
Binary log files (PUKE)
...which are really the first step towards a proper database holding log files, which I'd also love to see someday. Windows has its event service, which uses binary logs to fairly good effect, though it can get very slow for sorting and searching. A proper database is much better for that sort of thing, but I digress. As I understand, the binary format is trying to avoid being a full database, while still supporting filtering. It also seems to do a fairly decent job of separating user and system logs, and would allow filtering a single service or seeing the whole system's logs, without the current hassle of dealing with applications that don't properly declare who they are when logging.
Extremely poor documentation
This seems pretty subjective to me, so you'll need to do better for a complaint. When I've had to look up systemd documentation, it's been no worse (or much better) than any other GNU/Linux documentation.
Rushed to market with little objective testing
What, exactly, is "objective" testing for a completely different software architecture? The software managers I work with have been debating the essence of that question for the past few decades. That said, it's been out for five years. It is in active use, and working well enough for all normal purposes.
Bugs pile up with no resolution in sight, they just keep going for another dameon.
...So it's like any other software project? New development is usually the priority once something works well enough. I'll also note that within the last month, 60 bug reports have been closed on systemd's github tracker, and only 44 opened. The oldest bug is from June.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless.
No, you don't reboot servers, so your boot time is meaningless, but you have no justification to project that onto me. I actually work on a system with a requirement to cold-start the entire site in 15 minutes, from turning on the circuit breaker to being 100% ready for operation. My boot time is very meaningful.
As a sysadmin, I think it's to make my life miserable. As a user, I think it's because nobody gives a damn about logs for a system that's working.
After a quick search for the relevant document, it seems the default for stderr is to inherit settings, presumably from some kind of hierarchy that I don't know enough about to comment on. By default, then, I'd guess the top level discards logs.
From an architecture standpoint, that makes sense. On my work-related systems, I could just configure the top level, and get logs everywhere, or configure it for only the services that my system actually cares about. On the nearly-a-kiosk preconfigured laptop I gave to my mother, I don't need it to waste time or disk space recording logs that nobody will ever read. If I have to troubleshoot the machine, I'll turn on logging then.
Apparently in the "exec" part of a service, change StandardOutput or StandardError to one of:
inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console or socket
Microsoft: Yesterday's technology, tomorrow!
it happened over your continual vociferous objections
That's exactly the problem.
I have a dog in this fight. I'm a sysadmin, who often gets involved in engineering Linux-based systems. My top priority is that everything works reliably when I need it. I don't really care what style of startup scripts we use. If it's something I already know, that makes life easier in some ways, but I'm not so arrogant as to assume that a better way isn't possible. If that new system's better just because I know that somebody's reviewed their assumptions in the last decade, that alone is worth a bit.
Then there's Slashdot. While most rational discussions about systemd tend to discuss pros and cons, Slashdot's hivemind seems to have decided that systemd is simply evil, with no clear reason why. I understand that we're all traditionalists, but this often goes beyond common sense. As you've noted, the arguments are loud, repetitive, and vehement, and they've been going on for longer than I care to remember. There are no suggestions for improvement, other than to fork huge projects and insist that nothing can ever change.
Frankly, the objections are a bit old. They're often just reiterating rumors and outdated information, and contribute nothing to the conversation. I expect the developers have heard the objections, and either resolved the complaints or chosen intentionally to take a different path. As a community, can we please now move on to the next topic of discussion?