Hmm - there are PCMCIA card readers - used one for photography a long time ago...
If you have memory cards you're using in a camera, see whether there is a PCMCIA card reader for that type of card (used compact flash at the time). In that case you could at least use stuff you mostly have already...
Slashdot videos: Now with more Slashdot!
Hmm - there are PCMCIA card readers - used one for photography a long time ago...
That example isn't quite the same - noone will have a problem with Microsoft offering you a free coffee on their premises.
But, if Microsoft decided that Starbucks was a threat to them and started distributing free coffee everywhere just to screw up SBUX, then that would likely be an antitrust matter.
The same could be argued for a search engine offering a free office toolkit - as it's not really the typical pairing that has anything to do with their normal search business.
The free bag service is an anemity that you might come to expect from a hotel and AT the hotel's premises; or the free chauffeur service that they might offer to and from their hotel for your arrival and departure.
Indeed - no "stack"...
yet - unless google starts "integrating" the services into each other (integrate - not just share a home page as a starting point).
The stack example, indeed, seems misleading here.
On the other hand - while you defend google here - think back to some of the issues in the MS anti-trust case:
- MS used proceeds from other areas to funnel huge amounts of money into IE development - much more, than any start-up could hope to match.
- By including IE into Windows, for many people (normal users, not people working in IT) they eliminated the need to even look for other browsers - no matter, whether other browsers might have been better.
- The inclusion of IE also meant the end for commercial browser makers - as they wouldn't have an alternative source of income. "Netscape" failed, their browser ultimately only growing because it was completely freed and open-sourced: In effect, MS might still channel more money into IE; but against the open source community that would not necessarily help, as the open-source author doesn't need to "show quarterly numbers"; quarterly profit reports, etc -- as long as the open source developer gets an income (which in many cases may stem from an unrelated day-job)...
In google's case, there is no full integration of services - but:
- income from the advertising (which the search engine generates / facilitates) supports an ecosystem of other software - a free calendar or documents - services that _depend_ on their ad business generating the income for them. Same as MS Office paying the bills for IE.
- the same landing page (www.google.com) being a straight entry point to not just the search, but other free offerings unrelated to search (like the news, play,
These things make it more difficult for new enterprises to form - and it's reasonable to expect that any new area popping up on the web, google will not just also try to profit from (which would be fair enough), but they can (easily ab)use their position to help their apps further by giving them privileged exposure on their search page and continue to fund them for extended periods of time to prevent other entrants getting into that area.
Apparently, if you understand the seal's dialect, you'll clearly hear them say:
So long, and thanks for all the fish!
Question: How much of that complexity can you hide from the normal user? Or - how much of that complexity is even visible to the normal user?
Complexity often comes into two parts - the complexity for the developer or admin; and the complexity for the end-user.
If I use a Mac Desktop, you can bet I don't give much of a toss over how much extra work that might mean for a developer - as long as my user experience is better.
Do you drive a car?
I may agree with your point, that systemd is only useful for a subset of linux ecosystems - but from this, deriving that it shouldn't be default seems bizarre.
The "try to cover every possible thing" aspect that you so seem to hate for servers could be a boon for people installing it on laptops; or even their normal home PC; anyone starting out with linux.
In short - this could be a boon for a lot of people coming to Linux anew and don't know init.
So, why not leave systemd in "user centric" distros like standard ubuntu ; but keep init as default in server-distros - at least for the time being - since those are usually aimed at more experienced Unix users - who already know init.
If we can keep distros with and without a graphical desktop separate - why not do the systemd / init split along the same lines - as the desktop distros need to cater to being more user-friendly and more at home on very disparate hardware setups.
As for the optional step - if systemd may be more newbie friendly, how easy will it be to switch from init to systemd? And one of those two needs to be default - but if switching around between the two is tricky, then by all means take the more user-friendly one as standard - if the user-friendly option is difficult to install, you don't need to package it at all - as the newbie at whom you might aim it is probably the last person with the technical knowledge of what the switch means or how it could be done.
Hmm - strange how "nuking" people or places can be deemed a solution worthy of discussion.
Nukes are so well targetted - so, not just do you say "Turkey, UAE, and Saudi Arabia" support ISIL - but at the same time, that those countries have noone opposing any support for ISIL or radical islamics - and so if you nuke them, you're not going to hit anyone "innocent".
The only things nukes or other more military action do is to feed radicalism - and with rising radicalism on the other side, you will find more radical policies on our side "Nuke them!".
Military support is needed to help clean up the conflict - but it does need a longer term engagement, and it needs something else than airstrikes - but actual boots on the ground to prevent massacres. This is dangerous - it puts "our" soldiers sent there right in harms way, but we can't show people there a "better alternative" by delivering it in warheads.
Just like the ridiculous corporate taxes and corporate tax avoidance schemes, isn't it nice how we are worried about costs all the time - from TFA:
"Such changes could impact legitimate taxpayers by delaying refunds, extending tax season and likely adding costs to the IRS."
Sure, changes incur costs...
But, before you worry too much about possible costs - how much of "(the IRS) paid $5.2 billion in fraudulent identity theft refunds in filing season 2013" would the IRS need to block in future tax years to more than offset that cost?
If they're losing $5.2 bn a year - don't you think any reasonable costs invested to prevent those "losses" might not be a good investment?
Strange how, just a knee-jerk you'll find some people defending the science, there are those that have the same knee-jerk reaction against any findings in this area. With all that uncontrollable knee-jerking on both sides - it seems that we have another great argument for universal health care, to get people's knees fixed again... But I digress...
Whether climate change is man-made or not - I don't think there is too much debate left on the matter. But, I'm no climate scientist, so for me personally it's a matter of "belief" that mankind is behind this. We may get some theories and models wrong on how fast global warming works - or why there may be a hiatus in it.
The question of whether we're behind this - take two past events and see how much influence we might have:
Remember the Icelandic volcano a few years back - in response to the volcanic ash, we grounded a lot of flights for a few days - and even in that time, we could measure how much the air changed - just by taking planes out of the picture for a few days.
Secondly, if you think mankind's influence isn't large enough given the size of the planet - look back at climate records around the time Krakatoa blew up - that one mountain exploding had a measurable impact on temperature and weather for 5 years; so, if a _single_ mountain on one day can create that kind of change -- are you sure, all of our industries around the world together over the course of years CAN'T?
What the planet is "too large for", is for us to do some quick and easy experiments to actually test our hypotheses quickly - so climate science does what it can mostly from observation and trying to identify as many factors as possible that DO have a measurable impact in order to MODEL what's going to happen and then wait and see how close these models correlate with what's happening.
To some degree obviously, there is a lack of incentives for ISPs to change - if they still have enough addresses for themselves, then switching to IPv6 is only costs, not benefits.
Maybe some of the larger sites, like youtube, facebook, wikipedia should have a meeting to discuss the switch-over and then start shaping IPv4 traffic - just reduce capacity on IPv4 by 5% every month and see how long it will be, before ISPs will lose customers if they DON'T switch to IPv6...
I would guess they mean it's longer because they count its length as one piece - not as a lower leg and a foot.
Still - in terms of dimensions, it needs to be a good match with his other leg -- unlike Pistorius who would have been able to go for optimized prosthetics on both legs that would be better than "normal" legs might be... (i.e. watch the Aimee Mullins TED talk on how she can vary her height fairly significantly just through the choice of legs she wears)...
Hmm - I could partially understand the extra strength and mechanical advantage in the Pistorius case - I can't quite see it with Markus Rehm.
Pistorius had BOTH legs amputated, so you can potentially improve on both sides. Rehm had ONE leg amputated - adding extra length doesn't make any sense one one side only. Similarly, I would guess it would make it very difficult to run evenly, if the prosthetic leg doesn't about match the other one in length, in "bounce" (in the step),
I did not say purely that reading about -- should tell you about security alone. IIRC my original incident with -- was a colleague setting me a teaser on trying to find out how to delete a file called '-f'; and me first having to figure out, that 'rm ??' reads like delete all files with two character filenames (of which there was only the '-f' file), but not seeing that the ?? actually gets expanded to all the two character filenames by the shell; rm never sees the '??' but instead only sees the filenames - and obviously, it can't discern whether a parameter of '-f' was expanded from the filename -f or intentionally given as a parameter.
If you learn that - you'll get a better understanding of how the system works - and that _in turn_ will help you get a better grasp on what could or would go on and particularly, what could go WRONG, in a system.
Sorry, if that appears harsh - but sometimes it pays to read manuals and try and understand what you're doing and how the stuff works.
I don't exactly remember when I learnt it first - but I DID already know when I also got told about it during my CS BSc degree course (probably 1st or 2nd year - which would place it about 1998-2000).
If you need to code stuff "securely", you need to understand how stuff works -- I don't think of myself as a particularly apt security coder or hacker - I mainly specialise on internal systems integration, not so much web or other front-end stuff, so I have the luxury that I already know the data is "sane", before it gets to me - and I "only" need to figure out how to transform it and where to send it on to.
Here are a few pointers, where you might read about it:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character."
Even wikipedia mentions it - even though not strictly a "developer" resource:
"In Unix-like systems, the ASCII hyphen-minus is commonly used to specify options. The character is usually followed by one or more letters. Two hyphen-minus characters ( -- ) often indicate that the remaining arguments should not be treated as options, which is useful for example if a file name itself begins with a hyphen, or if further arguments are meant for an inner command. Double hyphen-minuses are also sometimes used to prefix "long options" where more descriptive option names are used. This is a common feature of GNU software. The getopt function and program, and the getopts command are usually used for parsing command-line options."
If that's too far to go - try "man getopt" on your linux machine:
The parameters getopt is called with can be divided into two parts:
options which modify the way getopt will parse (options and
-o|--options optstring in the SYNOPSIS), and the parameters which are
to be parsed (parameters in the SYNOPSIS). The second part will start
at the first non-option parameter that is not an option argument, or
after the first occurrence of `--'. If no `-o' or `--options' option
is found in the first part, the first parameter of the second part is
used as the short options string.
man rm - and even rm --help on linux show it:
To remove a file whose name starts with a '-', for example '-foo', use
one of these commands:
rm -- -foo
man chown doesn't mention it, but refers to the full documentation in texinfo and how to access it - that one says under "Common options"
Delimit the option list. Later arguments, if any, are treated as
operands even if they begin with `-'. For example, `sort -- -r'
reads from the file named `-r'.
The information is there - and in _lots_ of places - but it DOES require to occasionally read man pages or general intros, rather than using trial and error and just bodging around until something seems to work.
But, yes, it's a lot of material, and not everyone has the time to read everything -- for me this is also why I mostly rely on others to figure out system security issues... The problem to me seems more that a lot of "learn this in 5 mins" type tutorials don't include it purely for lack of time, and many just use those and still put the results up on the web somewhere.
Who does NOT use -- in their scripts, if they're safety conscious?
rm -i -- *
Normal programs should stop processing options after a (standalone) "--" and take everything following it as regular parameters. getopt and similar libraries handle this automatically.
I really wouldn't class the "use of wildcards" as a security risk - the security risk is the developer that doesn't know what he's doing.
Would command line handling be a security risk, if someone would add a --superuser-rm option to his code and execute "rm -rf