An ISP knows that it and it's customers are only in a certain ranges of addresses (which it allocated). Any IP packets leaving the ISP's network must, therefore, be within those ranges. It is trivial to add a border router egress filter that checks to see if the source address field is in the permitted range(s) and drops the packet if it isn't.
Dodgy ISPs may choose not to implement this, and so long as there is one dodgy ISP out there an attacker on that ISP (or tunneling traffic through a host on that ISP's network) can spoof IPs. That said, you either need to be on such an ISP or need to have access to a host that is (and that'll let you tunnel traffic through it). So it's not that easy.
Even if you can spoof source addresses, you are going to have a really hard time getting replies. The reply, of course, is routed to the real owner of that source address, which goes "WTF? This is a TCP reply packet for connection I never established" and drops it, sends an RST, or sends an appropriate ICMP error. This makes it rather hard to carry out a two-way TCP/IP conversation with spoofed IP addresses, as is required for things like spoofing the source address for the purpose of delivering email.
It's somewhat more useful with UDP/IP since you don't need to go through the TCP/IP connection handshake (which requires either 2-way communication or REALLY good guessing), so you can have a pretty effective monologue at the receiving host. This isn't useful for TCP/IP though because of the use of connection-specific sequence numbers and a handshake. Unless you can predict the sequence numbers, you're pretty much stuffed, and they're designed to be very hard to predict on decent operating systems.
Rather more complicated than:
telnet theirserver 25 HELO whatever-I-want MAIL FROM: spoofed@spoofed.net RCPT TO: someone@theirserver DATA From: spoofed@spoofed.net To: someone@theirserver Date: Subject: Ha Ha!
That's not true. IP addresses are way harder to spoof, not least because a well run upstream network will (mostly) prevent you from doing it though source IP filters etc.
This is not to say that IP addresses are, in absolute terms, hard to spoof. However, From: email addresses are so hilariously easy to spoof that all you need is a telnet client or a scripting language with any sort of mail or socket support.
Regarding mailing list subscriptions, that's not an entirely unreasonable suggestion, though it's really not much more than auto-whitelisting. However, you'd need to address the:
issue. People are stupid. Enough spammers are not stupid that they will trick stupid people. People will demand to be protected from their stupidity, and the filters will go back in.
The ability to examine your mailer whitelist and remove things from it would help, mostly because this can be made as easy as clicking the "Junk" button. With a little agreement an un-whitelisting could even generate an automatic unsubscribe.
To actually be useful, such a scheme would have to be combined with a sender verification system like SPF or DomainKeys. Lack of any sending server verification is basically a waste of time (spammers will just start mailbombing with mailing list sender addresses) and IP-based verification is way too inflexible.
Your biggest problem is that it's basically limited to being useful for mailing lists and perhaps regular correspondants. It also doesn't address ensuring that the confirmation message gets there in the first place (good luck figuring out how to do that!). Its limited scope means it's probably harder to get people to implement it, especially when they won't be making $1400 a pop for sender "approval" anymore.
I mostly play Battlefield 2142. It's a buggy piece of crap, but fun, and cheating is relatively unusual due to:
- Actively administrated servers & agressive banning of cheaters
- Well integrated and maintained PunkBuster
- Decent game maintenance
The game is not well written, but exploitable bugs do get fixed (usually fairly quickly) and cheating isn't so prevalent as to be a serious problem. I've definitely run into it a few times, and most of that was exploiting geometry glitches to get to places that shouldn't (yet) be reachable or to fire from inside solid structures. I've only ever encountered a one or two fairly obvious aimbots, though I'm sure they're around more than I notice.
The thing is, cheating doesn't make you smart. Giving yourself 360 degree vision with translucent walls and an aimbot will probably make you seriously lethal (if disoriented), but few cheats are that effective. An ordinary aimbot user still needs to be aware of you, facing roughly the right way, and to have fired in time. Being smarter and getting the drop on them with a knife (or sniper rifle) does the trick, as does running them over with a tank. The fact is that the majority of cheaters are in fact complete retards, and generally can't stand up to any decent player except in a direct firefight.
That said, BF2142 is designed so that players with improved tactics, better communications, more effective co-operation and a superior grasp of what their enemy is up to can beat twitch-gamer types more often than not. I can see how in, eg, CounterStrike, these people would get seriously annoying.
One doesn't have to write lots of brief replies to be useful.
Some of the most important and helpful - if less frequent - responses are ones that are longer explanations of complex problems or concepts. Disregarding these from consideration is... interesting.
In turn, I think the Cairo guys need some congratulations for making this possible. Without a good canvas, I don't think there's any way the Silverlight team could have done this so quickly.
While most countries with a level of social health care are indeed facing problems with it, mostly connected with the ageing population and the availability of expensive & time consuming treatments for many ailments of the elderly, it's not all bad.
For one, you don't have to use it. The public health system is *entirely* optional, and you can pay to get faster and often better treatment. Unfair? Definitely - but on the other hand, it (a) reduces the load on the public system, (b) helps pay for the development of technology the public system will later want to adopt, and (c) that's life.
More importantly, if you can't pay, it's a whole crapload better to have the offerings of the public health system than nothing.
I find it extremely depressing that here in Australia our government is butchering public hospital funding (among other things) to fund tax cuts. WTF?!? Since when did we become America? Maybe if the US adopts a degree of public health care our copy-cat government will start being a little bit more... decent.
I definitely take your point on malpractice insurance, though. It's a big problem even here now, and getting worse, but it's *nothing* like the US. IIRC some limits are now placed on payouts in recognition of the fact that (a) the money won't bring someone back, (b) beyond a certain point they offer little incentive for caution but rather just drive up insurance costs. I'm not sure, but I hope an exception has been made for funding long-term care of people who need it.
Hospital system aside, I'm always stunned to hear about people in the US not going to a GP because they can't afford it. At least that can't happen here (yet - our government is working hard on making it possible) due to the availability of GPs under the Medicare system.
I've been evaluating newspaper accounts and bookings systems recently. A key requirement is that I have some means of carrying on if the providing company goes out of business or is bought out. This means that I want something like a 3rd party support agent, code & documentation escrow, or some other form of safety net. I (well, the company I work for) has been burned before.
Companies will um and ah about such issues, then cry "look, a turkey!" and evaporate from the room. They reassure you about their continued profitability - and when you point to your past dealings, and to outfits like PeopleSoft (hardly unprofitable), they tend to get nervous.
If that were the only issue, the company I work for might bend. It's not. Most of this software is designed so that customers cannot effectively support and maintain it, it usually builds on top of various third party tools the developers have little control over (anybody who says "FileMaker can never go away" didn't see Visual FoxPro), and it's all arranged to make you dependent on them for ongoing support and licensing. You can't just buy the rights to use the damn thing and be able to go away if the quadruple the price for the next version.
We're now considering building in-house. Carefully. The result won't be as functional or have the same history of robustness, but it will be documented, designed to be maintained by any reasonably skilled software professional, and it'll be ours. It'll also, without any doubt, be much better than what we have (but so would pen & paper at this point). Thankfully there's practically no accounting involved and what there is just involves low level data to be fed into the main accounting system, so compliance won't be too much of a problem.
My point is that these are not just technical concerns. There are real business problems involved in these issues, and buying "turn-key solutions" may not always be the best long term decision for business infrastructure that cannot easily be swapped out. People think very hard about dependence on suppliers, individual employees, etc, but so rarely about dependence on critical pieces of software technology... until problems arise with them.
Funny - I build our intranet site for a known and controllable set of browsers too:
{ Mozilla Firefox }
though anything reasonably standards compliant should work. Consequently, doing "real" web development makes me want to cry at the horror and stupidity, and I'm seriously considering letting the site break for IE6 to further encourage people to at least get IE7.
Try this somewhere outside the USA... say, Australia. Apple charge a hefty "ha ha you don't live in the USA" markup that renders many of their products seriously pricey. That said, it doesn't seem to be as bad with the laptops.
You'll notice that Apple charge an apalling amount extra for sensible amounts of RAM for some of their models, so you must acquire 3rd party RAM in some cases (eg Mac Pro, XServe).
Good point regarding `using'. I'm a twit for not seeing that.
As for copious `using' statements... IMO it's a bad idea to:
- Reference a name imported with `using' from another context or re-import it with another `using' statement. Some compilers handle this, some do not. - Use `using' in almost any case. This is one of the few I'd consider, and even then only very carefully. - Import whole namespaces rather than individual freqently used names, unless the namespace is reasonably small and designed for that use. I particularly dislike `using namespace std'.
I do think people get too upset about `using' statements that are private to individual compilation units.
then b's object will be destroyed when it exits scope (due to an explicit or implicit return or an exception - not a long jump, but if you're using explicit long jumps you should be worrying about lots more than this). You also know that b will be destroyed before a. The semantics of copying `a' or `b' are well defined and transfer ownership, so you can return `a' and know you're transferring ownership.
If someone changes the above to:
{
auto_ptr<A> a(new A());
auto_ptr<B> b(new B()); // blah blah
if (!fred)
throw std::logic_error("oops!");
const Fred::const_iterator itEnd = fred->end();
for (Fred::const iterator it = fred->begin(); it != itEnd; ++it)
if (*it) return *it;
return 0xDEADBEEF;
}
then you can feel safe in the knowledge that they haven't introduced a leak of `a' or `b' without a genuine effort of stupidity.
More complex RAII mechanisms exist, but they all rely on the same core concepts of using the inherent lifetime of simpler objects to manage heap-allocated objects in safe and well defined ways.
(PS: Posting code combined with text with civilized formatting and line wrapping on./ SUCKS.)
Don't forget std::auto_ptr<>. It's a great and exception safe way to limit the lifetime of anything allocated using the non-array form of operator new
Whenever you see operator new or malloc() think "is there any chance any exception could be thrown between here and the call to operator delete or free()?" . If the answer is "yes", or you're feeling sensibly paranoid, wrap the allocated object up in a stack-based container (think std::auto_ptr and ilk) that'll deallocate it when it goes out of scope.
Consider transferring ownership of objects using std::auto_ptr so that you know that in your code, a "bare" ptr does not ever constitute ownership. This isn't viable if you hand memory to/from external libraries a lot, or use malloc() & free().
gcc has included most of tr1, especially , since at least 4.1. I think it was in 4.0 as well.
It's a pity there's no way to ensure compatibility between boost::shared_ptr and std::tr1::shared_ptr , nor a really attractive non-preprocessor-reliant mechanism to switch between them (since typedefs in C++ do not work on incomplete template types).
If your app is already reasonably portable, consider porting to Linux solely to use Valgrind. It's that good. Otherwise, have you looked at Rational's Purify? I haven't used it myself but hear it has some pluses and minuses as compared to Valgrind, but is worth a look.
I develop cross platform applications, and I find valgrind incredibly helpful, especially when integrated into my unit tests and combined with a suppressions file that hides any false positives from platform libraries etc.
As for shared_ptr, please DO NOT think of shared_ptr as a complete memory management and leak protection solution. Smart pointers in general and shared_ptr in particular are NOT a magic band aid. Slapping shared_ptr use into a design won't necessarily fix your lifetime & memory management issues, it's quite likely to just hide them and introduce new and fun bugs where object 1 *thought* it was manipulating object 2's fred, but it was actually manipulating an obsolete and unreferenced copy of object 2's fred. And so on. Ownership and lifetime still need careful thought, and it can be better to use good old auto_ptr<>, direct membership, etc rather than shared_ptr in many situations. Also remember that the use of dtors that affect anything outside the object its self is likely to lead directly to foaming insanity when combined with shared_ptr use.
Get your ownership and lifetime issues thought out well, and *then* think about introducing a shared ownership model if the situation warrants. Don't just slap shared_ptr<foo> in everywhere you use foo* and expect magic.
Your comment was well worthwhile. For one, you usually want to be using LVM on top of Linux software RAID anyway. And second, growing the array only works when ALL disks are replaced, not just some.
As for not noticing - I'd say very little about Linux software raid deserves a "dur". LVM is seriously nice and simple, but the software RAID layer is less so.
Scribus ships with a set of generic ICC profiles on all platforms where licensing permits (in other words, everything except Debian). Win32, Mac OS X and most Linux users will find that colour management may simply be turned on, and should be. Scribus bundles the crucial profiles like the Adobe RGB and sRGB profiles, SWOP Coated & Uncoated, Euroscale coated & uncoated, etc.
Debian users should enable the `non-free' respository and `apt-get install icc-profiles'. Debian policy prevents the maintainer of the Scribus packages from bundling them with the main package or having apt suggest or require the icc-profiles package.
Of course, you still want to find profiles for *your* source and target devices, do monitor calibration, etc. But that's nothing Scribus can help with and is the same issue any user of ICC-colour enabled applications faces. There is, however, some work that can be done on the user interface to make it a bit easier to understand how the profiles affect things, make it easier to pick a different target profile during PDF export, etc.
"Desktop Publishing (Indesign alternatives): Scribus looks the business, can anyone tell me if Scribus can import RGB Tiff's (for example) and colour separate them for print?"
Scribus will happily produce a CMYK PDF for you, and it'll do the RGB->CMYK conversion with appropriate colour profiles if you have them to get you a more accurate result. The resulting PDF will be acceptable to the vast majority of commercial printers. It can also generate PostScript separations (with some limitations, such as no transparency use in the source document) - however, I've *NEVER* had to supply a pre-separated document electronically. The last separations I sent in were in film we developed in house after outputting them on a laser imagesetter, and they were destined for the printers' camera-based plate-maker. Seriously ancient stuff.
These days, you supply a CMYK PDF (or with a modern printer, an ICC-tagged RGB PDF) and they send it to their RIP, which talks to the computer-controlled plate-maker and produces a plate. No mucking about with manual separations, etc.
InDesign does a great job of importing MS Word documents - within it's goals. The Adobe devs think like DTP people - "you use a word processor to create the text content, and the DTP app to lay it out". That means you should get good quality import of anything "in the text stream" but terrible or nonexistent handling of any attempt at layout using frames, absolute positioning, etc. That's correct behaviour, it's just not InDesign's job.
A "whole Word doc" -> InDesign importer might be useful, but the result would suck pretty badly and need a lot of cleaning up. Why bother when you can do it properly in ID from the start?
Scribus's OO.o importer was written with exactly the same viewpoint. It's not designed to handle "layouts" done in OO.o and these will not import in any useful way. It's designed to import formatted text. It's not perfect at that, largely due to limitations in Scribus 1.3.3.x regarding character styles etc, but is improving fast in 1.3.5 . The eventual goal is to import all in-line "flowing" content correctly, including things like OO.o-style tables & inline graphics. That's a while off, though.
Yep, lack of CMYK is a significant limitation in the GIMP, and it has some issues. I wouldn't characterize it as a "toy" by any stretch, however, and I've found it quite capable for much of the work I do. The biggest day-to-day complaint I run into is its' inferior performance and previews as compared to Photoshop.
I don't consider lack of 16 bit RGB support a crippling problem for all workflows. Certainly, along with limited RAW support and lack of any sort of ICC colour management it's a problem for high-end photography work, but it's not really a killer for many uses. In fact, the newspaper I work with uses 8-bit colour all the way through its workflow at the moment - and while we'd probably benefit from moving to 16-bit colour for image archival and manipulation, it really doesn't make that much difference for many uses.
I have a much bigger problem with the lack of ICC colour support and CMYK support. You need at least one or the other for a print-targeted workflow, with both strongly preferable. If you only have ICC colour support, you'll need DTP apps that can do the right thing with tagged images, and you won't want to be working on really difficult images that need fine-tuning after colour space conversion. And if you only have CMYK support you'd better have a decent external tool with ICC colour support to the RGB->CMYK conversion, or the result will be muck.
It's exciting to see all the work going in to GEGL (the core for the new GIMP revision with much-improved support of ICC colour, multiple colour spaces, higher bit depths, non-destructive workflow, etc) and I can't wait until some of that starts appearing in a reasonably usable form. Their approach to non-destructive editing & history is the first thing I've seen in GIMP that makes me sit up and take notice when working on Photoshop.
You don't have to do that just to use extra capacity on Linux software RAID 5 disks. Once every drive has been replaced with one of a higher capacity, mdadm can be asked to expand the array onto the unallocated space on the disks, bringing the per-disk used size up to the capacity of the smallest disk.
If you're using mixed sizes this doesn't work, of course, and then you benefit from grafting them together with lvm as you suggested.
I tend to use LVM to manage the storage as a matter of course, but prefer to keep the RAID array fairly simple.
Subversion can be quite useful for a project's "authorative" repository. Especially if that project used to successfully use CVS, as a great many small projects do/did - and some larger ones, like GNOME and KDE, too. Subversion is also quite convenient for publishing sources, though it's less than ideal for any contributors without commit trying to work from anonsvn.
svn is supported by a number of IDE plugins & GUIs, which a surprisingly large number of people use and come to rely on. I'm not one of them, but many of the folks I work with use various svn guis.
git-svn looks very interesting, as it should provide a way to add distributed scm capabilities on top of svn, where you're working with projects that use svn. It'd be useful even just for the ability to take partial local history and keep local modifications under revision control. I wonder if there's anything similar for Mercurial...
What bothers me most about svn is the insufficient integrity guarantee on the repository. That, however, can be fixed, and I hope it's going to be addressed with an `fsfs2' format. Frankly, not everyone *needs* distributed SCM, and many are quite fine with a good centralized system.
The test you did is not conclusive by any means. You must also prove that the address was never exposed in any other way (stolen by malware on your machine, leaked through other communications, sold by a corrupt mail server administrator, etc), OR you need to find conclusive evidence that the leaked address came from the company's end.
I've seen addresses turn up in spam that I wouldn't have believed if I hadn't seen it.
Now, if you are able to confirm that several addreses created by different people & never shared get similar scams that addresses not given to the company DO NOT get, then that might be something interesting.
Please drop the "no registry changes" requirement. A "no registry changes outside appropriate application-specific areas" rule is much more appropriate.
A program can quite reasonably create its own software configuration tree in HKLM\Software and/or HKCU\Software . It's even reasonable to have a dpkg-like --purge that deletes that tree, though it might be preferable to only do that to software in a subdir like HKCU\Software\WinPkg and patch all your apps to put their config in there. Not sure.
What programs should not be doing is poking around in other apps' registry entries or changing system registry settings.
It's a bit like having policy that packages may create configuration files in/etc, including adding them to config.d directories for other packages, but may not overwrite or modify config files managed by other packages.
Actually, you can fairly reasonably support open source and oppose copyright - as while donating your work into the public domain is "purer" and closer to that goal, practical realities make open source licenses like the BSD/X11/MIT licenses more practical.
It makes little sense to support Free Software (in the GNU/FSF sense) and support the abolition of copyright, since as the essay author noted, Free Software depends on copyright to enforce the restrictions applied by the license.
It is most unfortunate that the article submitter and the essay writer confuse open source and free software while attempting to comment on others' confusion about aspects of them. That said, the confusion could well be a matter of wording, as there are no really gross misunderstandings there.
In any case - boring and well understood by anybody who's going to read and understand that essay.
Slashdot Mirror
An ISP knows that it and it's customers are only in a certain ranges of addresses (which it allocated). Any IP packets leaving the ISP's network must, therefore, be within those ranges. It is trivial to add a border router egress filter that checks to see if the source address field is in the permitted range(s) and drops the packet if it isn't.
... isn't it?
Dodgy ISPs may choose not to implement this, and so long as there is one dodgy ISP out there an attacker on that ISP (or tunneling traffic through a host on that ISP's network) can spoof IPs. That said, you either need to be on such an ISP or need to have access to a host that is (and that'll let you tunnel traffic through it). So it's not that easy.
Even if you can spoof source addresses, you are going to have a really hard time getting replies. The reply, of course, is routed to the real owner of that source address, which goes "WTF? This is a TCP reply packet for connection I never established" and drops it, sends an RST, or sends an appropriate ICMP error. This makes it rather hard to carry out a two-way TCP/IP conversation with spoofed IP addresses, as is required for things like spoofing the source address for the purpose of delivering email.
It's somewhat more useful with UDP/IP since you don't need to go through the TCP/IP connection handshake (which requires either 2-way communication or REALLY good guessing), so you can have a pretty effective monologue at the receiving host. This isn't useful for TCP/IP though because of the use of connection-specific sequence numbers and a handshake. Unless you can predict the sequence numbers, you're pretty much stuffed, and they're designed to be very hard to predict on decent operating systems.
Rather more complicated than:
telnet theirserver 25
HELO whatever-I-want
MAIL FROM: spoofed@spoofed.net
RCPT TO: someone@theirserver
DATA
From: spoofed@spoofed.net
To: someone@theirserver
Date:
Subject: Ha Ha!
Body Text
.
That's not true. IP addresses are way harder to spoof, not least because a well run upstream network will (mostly) prevent you from doing it though source IP filters etc.
This is not to say that IP addresses are, in absolute terms, hard to spoof. However, From: email addresses are so hilariously easy to spoof that all you need is a telnet client or a scripting language with any sort of mail or socket support.
Regarding mailing list subscriptions, that's not an entirely unreasonable suggestion, though it's really not much more than auto-whitelisting. However, you'd need to address the:
m @sending.domain.com>
From: "Sexy Chick" <confirm-12312312-from=mailouts=sending.domain.co
Reply for an exciting photo!
issue. People are stupid. Enough spammers are not stupid that they will trick stupid people. People will demand to be protected from their stupidity, and the filters will go back in.
The ability to examine your mailer whitelist and remove things from it would help, mostly because this can be made as easy as clicking the "Junk" button. With a little agreement an un-whitelisting could even generate an automatic unsubscribe.
To actually be useful, such a scheme would have to be combined with a sender verification system like SPF or DomainKeys. Lack of any sending server verification is basically a waste of time (spammers will just start mailbombing with mailing list sender addresses) and IP-based verification is way too inflexible.
Your biggest problem is that it's basically limited to being useful for mailing lists and perhaps regular correspondants. It also doesn't address ensuring that the confirmation message gets there in the first place (good luck figuring out how to do that!). Its limited scope means it's probably harder to get people to implement it, especially when they won't be making $1400 a pop for sender "approval" anymore.
I mostly play Battlefield 2142. It's a buggy piece of crap, but fun, and cheating is relatively unusual due to:
- Actively administrated servers & agressive banning of cheaters
- Well integrated and maintained PunkBuster
- Decent game maintenance
The game is not well written, but exploitable bugs do get fixed (usually fairly quickly) and cheating isn't so prevalent as to be a serious problem. I've definitely run into it a few times, and most of that was exploiting geometry glitches to get to places that shouldn't (yet) be reachable or to fire from inside solid structures. I've only ever encountered a one or two fairly obvious aimbots, though I'm sure they're around more than I notice.
The thing is, cheating doesn't make you smart. Giving yourself 360 degree vision with translucent walls and an aimbot will probably make you seriously lethal (if disoriented), but few cheats are that effective. An ordinary aimbot user still needs to be aware of you, facing roughly the right way, and to have fired in time. Being smarter and getting the drop on them with a knife (or sniper rifle) does the trick, as does running them over with a tank. The fact is that the majority of cheaters are in fact complete retards, and generally can't stand up to any decent player except in a direct firefight.
That said, BF2142 is designed so that players with improved tactics, better communications, more effective co-operation and a superior grasp of what their enemy is up to can beat twitch-gamer types more often than not. I can see how in, eg, CounterStrike, these people would get seriously annoying.
One doesn't have to write lots of brief replies to be useful.
... interesting.
Some of the most important and helpful - if less frequent - responses are ones that are longer explanations of complex problems or concepts. Disregarding these from consideration is
In turn, I think the Cairo guys need some congratulations for making this possible. Without a good canvas, I don't think there's any way the Silverlight team could have done this so quickly.
While most countries with a level of social health care are indeed facing problems with it, mostly connected with the ageing population and the availability of expensive & time consuming treatments for many ailments of the elderly, it's not all bad.
... decent.
For one, you don't have to use it. The public health system is *entirely* optional, and you can pay to get faster and often better treatment. Unfair? Definitely - but on the other hand, it (a) reduces the load on the public system, (b) helps pay for the development of technology the public system will later want to adopt, and (c) that's life.
More importantly, if you can't pay, it's a whole crapload better to have the offerings of the public health system than nothing.
I find it extremely depressing that here in Australia our government is butchering public hospital funding (among other things) to fund tax cuts. WTF?!? Since when did we become America? Maybe if the US adopts a degree of public health care our copy-cat government will start being a little bit more
I definitely take your point on malpractice insurance, though. It's a big problem even here now, and getting worse, but it's *nothing* like the US. IIRC some limits are now placed on payouts in recognition of the fact that (a) the money won't bring someone back, (b) beyond a certain point they offer little incentive for caution but rather just drive up insurance costs. I'm not sure, but I hope an exception has been made for funding long-term care of people who need it.
Hospital system aside, I'm always stunned to hear about people in the US not going to a GP because they can't afford it. At least that can't happen here (yet - our government is working hard on making it possible) due to the availability of GPs under the Medicare system.
It's not that simple.
... until problems arise with them.
I've been evaluating newspaper accounts and bookings systems recently. A key requirement is that I have some means of carrying on if the providing company goes out of business or is bought out. This means that I want something like a 3rd party support agent, code & documentation escrow, or some other form of safety net. I (well, the company I work for) has been burned before.
Companies will um and ah about such issues, then cry "look, a turkey!" and evaporate from the room. They reassure you about their continued profitability - and when you point to your past dealings, and to outfits like PeopleSoft (hardly unprofitable), they tend to get nervous.
If that were the only issue, the company I work for might bend. It's not. Most of this software is designed so that customers cannot effectively support and maintain it, it usually builds on top of various third party tools the developers have little control over (anybody who says "FileMaker can never go away" didn't see Visual FoxPro), and it's all arranged to make you dependent on them for ongoing support and licensing. You can't just buy the rights to use the damn thing and be able to go away if the quadruple the price for the next version.
We're now considering building in-house. Carefully. The result won't be as functional or have the same history of robustness, but it will be documented, designed to be maintained by any reasonably skilled software professional, and it'll be ours. It'll also, without any doubt, be much better than what we have (but so would pen & paper at this point). Thankfully there's practically no accounting involved and what there is just involves low level data to be fed into the main accounting system, so compliance won't be too much of a problem.
My point is that these are not just technical concerns. There are real business problems involved in these issues, and buying "turn-key solutions" may not always be the best long term decision for business infrastructure that cannot easily be swapped out. People think very hard about dependence on suppliers, individual employees, etc, but so rarely about dependence on critical pieces of software technology
Funny - I build our intranet site for a known and controllable set of browsers too:
{ Mozilla Firefox }
though anything reasonably standards compliant should work. Consequently, doing "real" web development makes me want to cry at the horror and stupidity, and I'm seriously considering letting the site break for IE6 to further encourage people to at least get IE7.
Try this somewhere outside the USA... say, Australia. Apple charge a hefty "ha ha you don't live in the USA" markup that renders many of their products seriously pricey. That said, it doesn't seem to be as bad with the laptops.
You'll notice that Apple charge an apalling amount extra for sensible amounts of RAM for some of their models, so you must acquire 3rd party RAM in some cases (eg Mac Pro, XServe).
Good point regarding `using'. I'm a twit for not seeing that.
... IMO it's a bad idea to:
As for copious `using' statements
- Reference a name imported with `using' from another context or re-import it with another `using' statement. Some compilers handle this, some do not.
- Use `using' in almost any case. This is one of the few I'd consider, and even then only very carefully.
- Import whole namespaces rather than individual freqently used names, unless the namespace is reasonably small and designed for that use. I particularly dislike `using namespace std'.
I do think people get too upset about `using' statements that are private to individual compilation units.
Not really - you can rely on the standard & guaranteed rules about the behaviour of stack objects.
You know that if you have:
{
// blah blah
auto_ptr<A> a(new A());
auto_ptr<B> b(new B());
}
then b's object will be destroyed when it exits scope (due to an explicit or implicit return or an exception - not a long jump, but if you're using explicit long jumps you should be worrying about lots more than this). You also know that b will be destroyed before a. The semantics of copying `a' or `b' are well defined and transfer ownership, so you can return `a' and know you're transferring ownership.
If someone changes the above to:
{
// blah blah
auto_ptr<A> a(new A());
auto_ptr<B> b(new B());
if (!fred)
throw std::logic_error("oops!");
const Fred::const_iterator itEnd = fred->end();
for (Fred::const iterator it = fred->begin(); it != itEnd; ++it)
if (*it) return *it;
return 0xDEADBEEF;
}
then you can feel safe in the knowledge that they haven't introduced a leak of `a' or `b' without a genuine effort of stupidity.
More complex RAII mechanisms exist, but they all rely on the same core concepts of using the inherent lifetime of simpler objects to manage heap-allocated objects in safe and well defined ways.
(PS: Posting code combined with text with civilized formatting and line wrapping on ./ SUCKS.)
Some more points:
gcc has included most of tr1, especially , since at least 4.1. I think it was in 4.0 as well.
It's a pity there's no way to ensure compatibility between boost::shared_ptr and std::tr1::shared_ptr , nor a really attractive non-preprocessor-reliant mechanism to switch between them (since typedefs in C++ do not work on incomplete template types).
If your app is already reasonably portable, consider porting to Linux solely to use Valgrind. It's that good. Otherwise, have you looked at Rational's Purify? I haven't used it myself but hear it has some pluses and minuses as compared to Valgrind, but is worth a look.
I develop cross platform applications, and I find valgrind incredibly helpful, especially when integrated into my unit tests and combined with a suppressions file that hides any false positives from platform libraries etc.
As for shared_ptr, please DO NOT think of shared_ptr as a complete memory management and leak protection solution. Smart pointers in general and shared_ptr in particular are NOT a magic band aid. Slapping shared_ptr use into a design won't necessarily fix your lifetime & memory management issues, it's quite likely to just hide them and introduce new and fun bugs where object 1 *thought* it was manipulating object 2's fred, but it was actually manipulating an obsolete and unreferenced copy of object 2's fred. And so on. Ownership and lifetime still need careful thought, and it can be better to use good old auto_ptr<>, direct membership, etc rather than shared_ptr in many situations. Also remember that the use of dtors that affect anything outside the object its self is likely to lead directly to foaming insanity when combined with shared_ptr use.
Get your ownership and lifetime issues thought out well, and *then* think about introducing a shared ownership model if the situation warrants. Don't just slap shared_ptr<foo> in everywhere you use foo* and expect magic.
Your comment was well worthwhile. For one, you usually want to be using LVM on top of Linux software RAID anyway. And second, growing the array only works when ALL disks are replaced, not just some.
As for not noticing - I'd say very little about Linux software raid deserves a "dur". LVM is seriously nice and simple, but the software RAID layer is less so.
Scribus ships with a set of generic ICC profiles on all platforms where licensing permits (in other words, everything except Debian). Win32, Mac OS X and most Linux users will find that colour management may simply be turned on, and should be. Scribus bundles the crucial profiles like the Adobe RGB and sRGB profiles, SWOP Coated & Uncoated, Euroscale coated & uncoated, etc.
Debian users should enable the `non-free' respository and `apt-get install icc-profiles'. Debian policy prevents the maintainer of the Scribus packages from bundling them with the main package or having apt suggest or require the icc-profiles package.
Of course, you still want to find profiles for *your* source and target devices, do monitor calibration, etc. But that's nothing Scribus can help with and is the same issue any user of ICC-colour enabled applications faces. There is, however, some work that can be done on the user interface to make it a bit easier to understand how the profiles affect things, make it easier to pick a different target profile during PDF export, etc.
"Desktop Publishing (Indesign alternatives): Scribus looks the business, can anyone tell me if Scribus can import RGB Tiff's (for example) and colour separate them for print?"
Scribus will happily produce a CMYK PDF for you, and it'll do the RGB->CMYK conversion with appropriate colour profiles if you have them to get you a more accurate result. The resulting PDF will be acceptable to the vast majority of commercial printers. It can also generate PostScript separations (with some limitations, such as no transparency use in the source document) - however, I've *NEVER* had to supply a pre-separated document electronically. The last separations I sent in were in film we developed in house after outputting them on a laser imagesetter, and they were destined for the printers' camera-based plate-maker. Seriously ancient stuff.
These days, you supply a CMYK PDF (or with a modern printer, an ICC-tagged RGB PDF) and they send it to their RIP, which talks to the computer-controlled plate-maker and produces a plate. No mucking about with manual separations, etc.
InDesign does a great job of importing MS Word documents - within it's goals. The Adobe devs think like DTP people - "you use a word processor to create the text content, and the DTP app to lay it out". That means you should get good quality import of anything "in the text stream" but terrible or nonexistent handling of any attempt at layout using frames, absolute positioning, etc. That's correct behaviour, it's just not InDesign's job.
A "whole Word doc" -> InDesign importer might be useful, but the result would suck pretty badly and need a lot of cleaning up. Why bother when you can do it properly in ID from the start?
Scribus's OO.o importer was written with exactly the same viewpoint. It's not designed to handle "layouts" done in OO.o and these will not import in any useful way. It's designed to import formatted text. It's not perfect at that, largely due to limitations in Scribus 1.3.3.x regarding character styles etc, but is improving fast in 1.3.5 . The eventual goal is to import all in-line "flowing" content correctly, including things like OO.o-style tables & inline graphics. That's a while off, though.
Yep, lack of CMYK is a significant limitation in the GIMP, and it has some issues. I wouldn't characterize it as a "toy" by any stretch, however, and I've found it quite capable for much of the work I do. The biggest day-to-day complaint I run into is its' inferior performance and previews as compared to Photoshop.
I don't consider lack of 16 bit RGB support a crippling problem for all workflows. Certainly, along with limited RAW support and lack of any sort of ICC colour management it's a problem for high-end photography work, but it's not really a killer for many uses. In fact, the newspaper I work with uses 8-bit colour all the way through its workflow at the moment - and while we'd probably benefit from moving to 16-bit colour for image archival and manipulation, it really doesn't make that much difference for many uses.
I have a much bigger problem with the lack of ICC colour support and CMYK support. You need at least one or the other for a print-targeted workflow, with both strongly preferable. If you only have ICC colour support, you'll need DTP apps that can do the right thing with tagged images, and you won't want to be working on really difficult images that need fine-tuning after colour space conversion. And if you only have CMYK support you'd better have a decent external tool with ICC colour support to the RGB->CMYK conversion, or the result will be muck.
It's exciting to see all the work going in to GEGL (the core for the new GIMP revision with much-improved support of ICC colour, multiple colour spaces, higher bit depths, non-destructive workflow, etc) and I can't wait until some of that starts appearing in a reasonably usable form. Their approach to non-destructive editing & history is the first thing I've seen in GIMP that makes me sit up and take notice when working on Photoshop.
You don't have to do that just to use extra capacity on Linux software RAID 5 disks. Once every drive has been replaced with one of a higher capacity, mdadm can be asked to expand the array onto the unallocated space on the disks, bringing the per-disk used size up to the capacity of the smallest disk.
If you're using mixed sizes this doesn't work, of course, and then you benefit from grafting them together with lvm as you suggested.
I tend to use LVM to manage the storage as a matter of course, but prefer to keep the RAID array fairly simple.
Subversion can be quite useful for a project's "authorative" repository. Especially if that project used to successfully use CVS, as a great many small projects do/did - and some larger ones, like GNOME and KDE, too. Subversion is also quite convenient for publishing sources, though it's less than ideal for any contributors without commit trying to work from anonsvn.
svn is supported by a number of IDE plugins & GUIs, which a surprisingly large number of people use and come to rely on. I'm not one of them, but many of the folks I work with use various svn guis.
git-svn looks very interesting, as it should provide a way to add distributed scm capabilities on top of svn, where you're working with projects that use svn. It'd be useful even just for the ability to take partial local history and keep local modifications under revision control. I wonder if there's anything similar for Mercurial...
What bothers me most about svn is the insufficient integrity guarantee on the repository. That, however, can be fixed, and I hope it's going to be addressed with an `fsfs2' format. Frankly, not everyone *needs* distributed SCM, and many are quite fine with a good centralized system.
The test you did is not conclusive by any means. You must also prove that the address was never exposed in any other way (stolen by malware on your machine, leaked through other communications, sold by a corrupt mail server administrator, etc), OR you need to find conclusive evidence that the leaked address came from the company's end.
I've seen addresses turn up in spam that I wouldn't have believed if I hadn't seen it.
Now, if you are able to confirm that several addreses created by different people & never shared get similar scams that addresses not given to the company DO NOT get, then that might be something interesting.
Please drop the "no registry changes" requirement. A "no registry changes outside appropriate application-specific areas" rule is much more appropriate.
/etc, including adding them to config.d directories for other packages, but may not overwrite or modify config files managed by other packages.
A program can quite reasonably create its own software configuration tree in HKLM\Software and/or HKCU\Software . It's even reasonable to have a dpkg-like --purge that deletes that tree, though it might be preferable to only do that to software in a subdir like HKCU\Software\WinPkg and patch all your apps to put their config in there. Not sure.
What programs should not be doing is poking around in other apps' registry entries or changing system registry settings.
It's a bit like having policy that packages may create configuration files in
Actually, you can fairly reasonably support open source and oppose copyright - as while donating your work into the public domain is "purer" and closer to that goal, practical realities make open source licenses like the BSD/X11/MIT licenses more practical.
It makes little sense to support Free Software (in the GNU/FSF sense) and support the abolition of copyright, since as the essay author noted, Free Software depends on copyright to enforce the restrictions applied by the license.
It is most unfortunate that the article submitter and the essay writer confuse open source and free software while attempting to comment on others' confusion about aspects of them. That said, the confusion could well be a matter of wording, as there are no really gross misunderstandings there.
In any case - boring and well understood by anybody who's going to read and understand that essay.