It's called sticking with their current codebase and growing from that, being careful not to look at any code submitted post GPL3 of a given codebase. It's a pain and becomes more so over time, but realistically speaking I doubt many new core platform enhancements are really significant for Tivo's functionality. They already constructed a hardware platform and set of running processes such that things run that meet real-time-like needs, therefore hypothetical scheduling improvements buys them nothing. Filesystem/storage device drivers are similarly moot, since they already work, and they don't intend on supporting more complex configurations that such featurs could help with. The fundamental utilities meet their needs today. The open network ports they have are likely controlled by their proprietary software, or if they do have some such software with a vulnerability fixed only in the GPL3 tree, then undoubtedly they could find an alternative project that didn't go GPL3 (even if it is a commercial product) to use.
If I had to make a decision with goals like Tivo's in mind, I probably would have gone for a BSD codebase. BSD explicitly aims for what the makers of Tivo would be comfortable with. Doesn't preclude them from giving back, but doesn't hold the accountable for not giving back either. Think GPL is great for the community, but a company looking to for all intents and purposes exploit free software developers may not be able to deal with GPL, and BSD developers welcome the opportunity to get their code wherever, so long as they get credit where it is due.
They aren't implying that either math ability or long ring fingers *cause* the other, simply that there is some apparent statistical correlation. The put forth a hypothesis on something they believe would be a common cause for both situations, but do not say they cause one another.
Is people insisting on high-performance RAID knowing full well that the system will only ever do NFS/SMB serving, not running any more complex processes locally, and accessing the disks via a single gigabit link. Or assuming absolutely that a RAID controller that is true hardware is guaranteed to be faster. I have seen RAID controllers where, true, the processor usage/throughput was technically lower (meaning the already largely idle cpus were more idle), the hardware engine on the card would hit its cap in performance well before the processor would hit any cap. Basically, if your criteria is 'must be hardware RAID', without any specific metrics and without researching the quantified performance numbers for the cards being looked into, then I think software RAID is probably really the answer.
Adding to your point about differing sets of tools, if you have an 8-year old server the raid controller goes out on, your chances of finding a compatible controller that can understand and import that array is slim, so you could have to rely unnecessarily on your backups just because your hardware vendor doesn't support you anymore. Hardware RAID has a lot of disadvantages.
It's been a long time, but the Windows 2000 server I used to admin back in the day, software raid was integrated into the 'disk management' MMC plugin. I believe last I checked on a non-'server' MS install (2000 workstation), software raid beyond simple mirroring was not available (at least I couldn't find the same way to enable it I did on the server OS).
This was rather vague, but I know MS does this as well (that's one of the installs where I had to rebuild the array from it thinking two drives went bad concurrently). I'm sure google can help in more detail (it's obviously been years since I had to be a Windows admin, never even touched Server 2003).
Hm, guess I should have more specifically said didn't see the point for me. Most all of those bullet points can be implemented at the OS layer in a cross-platform manner using an OS without draconian licensing for client access count. However, admittedly, you must have a perhaps more competent admin as implementing some of these features is not as trivial as what the NAS vendors may do for you.
The one thing that stands out as lacking would be a true versioned copy-on-write system. Currently everything I mess with is contigent on point-in-time snapshotting, if you make two changes to a file between snapshots, that one change is lost.
Avoiding single point of failure is about more than the cables between systems. Most architected SAN solutions are paranoid about even solid-state component failure. I.e. a RAID controller determines it has bad cache memory. In a typical SAN architecture, the controller notes the presence of a peer controller, throws up its hands, says replace me, and the other controller takes over, while the other controller is presumably hot swapped. If your controller with direct connected drives fails, well, that was your single point of failure. Your server suffers a catastrophic failure (PCI fault, processor fault, uncorrectable ECC), you have lost access to your storage. If you implement anything fancier (i.e. with multiple systems, talking to multiple controllers each with multiple paths to each individual drive), then by definition it becomes a SAN. Feel free to replace the FC fabric with iSCSI, or whatever commonly supported block-device-oriented strategy you want, it's still a SAN. Feel free to run ZFS on top of a SAN, though perhaps only in an active-passive way.
BTW, in many many ungodly amounts of explicit storage testing for data miscompare situations (why you would need above-block-layer checksuming), I have yet to see a single instance not caught by individual hard drive ECC mechanisms. I consider ZFS' checksumming nifty and good for demos involving dd and random data with an array member, but in real-world situations, it is largely redundant. Checksumming is done in lower levels transparently to the user, it's more of an assumed must-have than a 'hey look, we checksum!'. The checksumming would only catch errors that probably are obvious and caught before they ever reach ZFS. Now one thing I would like to see something do is upon seeing a bad block reported from a lower level, automatically go back and attempt to write back that one block of data based on other array member data. Bad block reallocation is nice for writes, but I have seen one array where by the time one bad, unrecoverable block was detected, other members of the array also had unrecoverable blocks in other places. All the data was still there, but the array wanted N-1 100% good members for the entire data set, instead of N-1 100% good members on a block-by-block basis. If instead of kicking out of the array, it would have rewritten the data it could then interpolate from other members, just a disaster would be averted (just monitor the SMART reported bad block reallocation count.)
Depending on the scale and application of the fileserver, generic OS provided software RAID will probably be more robust/recoverable than hardware RAID, without an unacceptable degradation in performance. I have, for example, an Adaptec 2410SA RAID adapter. The performance is not compelling, but the deal breaker for me is the card had on occasion, lost it's mind on unclean system reset. The drives were out of the array and that adapter offered no 'put together and assume it was a RAID-5 with this layout before, just sync the parity', so the data was non-trivially unavailable. With linux software RAID in particular (and the one time with Windows software RAID that I had to maintain as well), the tools in terms of what conditions can be recovered from and how it is to do are pretty smart and flexible. Both architectures I saw systems that decided (wrongly so) to put multiple drives on a single IDE channel and wrap in software RAID. A drive would effectively knock out accessibility for the other and the array would lose two members. For many hardware controllers, that would be 'the end'. Software RAID I was able to say 'assemble this array and assume I know what I'm talking about', and recover data without resorting to other backups which were inconvenient, or non-existant.
Some situations, you have particular hard throughput requirements you can quantify, in which case you may have little choice. Keep in mind if just doing simple file storage sharing (NFS/SMB) primarily over a single gigabit link or worse, you have really nothing much to gain from a high-performance internal subsystem. If you have local-storage for a high TPC database system or some disk intensive modeling or something, that's where you really start thinking about hardware controllers, IMHO,
You never know when the latest and greatest bleeding edge version You obviously have never used a stable debian or even a post-release ubuntu distribution. Once set, they (like most distros after release) do precisely what you prescribe, do not strictly follow upstream, but rather backport security/bug fixes to the same exact version they declared release at. As soon as Ubuntu 7.04 released, that was it for upstream enhancements, and the versions were frozen. Now only bug and security updates come. If you truly fear the updates, the updates do not auto-apply by default anyway. They auto-notify. They then include a fairly detailed changelog generally as to exactly what is the intent of the update. You want to run a server with confidence that the updates will be conservative, go with RHEL5,CentOS5,Debian Etch, or Ubuntu 6.06. Absolutely those systems have your needs in mind with regards to being conservative. The vast majority of distributions out there today either totally embrace the fear you have or have some path to follow that would be appropriate with those fears in mind.
Distributions like gentoo subscribe to a philosophy that goes down the path you fear, leave the decisions to upstream as to how to go 99% of the time. This philosophy has a place, but as you have pointed out, what upstream considers 'minor revisions' can vary greatly and never preclude feature behavior changes. Even if you simply tracked GLSA, more often than not the 'answer' is to update to a new revision of the package in question which is not precluded from new features being implemented or old ones changed. If you run Gentoo, you should know what you are getting into and what you are getting in exchange for that concession.
ZFS does not obsolete NAS/SAN. However, for many many many instances, DIY fileservers have been more appropriate than SAN or NAS situations for many concepts long before ZFS came along, and ZFS has done little to change that situation (though adminning ZFS is more straightfoward and in some ways more efficient than the traditional, disparate strategies to achieve the same thing).
I haven't gotten the point of standalone NAS boxes. They always were not fundamentally different from a traditional server, but with a premium price attached. I may not have seen the high-end stuff, howerver.
SAN is an entirely different situation all together. You could have ZFS implemented on top of a SAN-backed block device (though I don't know if ZFS has any provisions to make this desirable). SAN is about solid performance to a number of nodes with extreme availability in mind. Most of the time in a SAN, every hard drive would be a member of a RAID, with each drive having two paths to power and to two RAID controllers in the chassis, each RAID controller having two uplinks to either two hosts or two FC switches, and each host either having two uplinks to the two different controllers or to two FC switches. Obviously, this gets pricey for good reason which may or may not be applicable to your purposes (frequently not), but the point of most SAN situations is no single-point of failure. For simple operation of multiple nodes on a common block device, HA is used to decide which single node owns/mounts any FS at a given time. Other times, a SAN filesystem like GPFS is used to mount the block device concurrenlty among many nodes, for active-active behavior.
For the common case of 'decently' availble storage, a robust server with RAID arrays has for a long time been more appropriate for the majority of uses.
I concur in general that the concept of an extended adolescence is an artifact of modern society, but at the same time it may be a mistake to dismiss something that has evolved in society as merely artificial and therefore safe to put aside. In "ye olde tymes" life was simpler. By no means easier or safer, in fact very much the opposite, but simple. By 13/14, you had realistically learned everything you would need to operate successfully in 98% of the adult society. Children grew up young because the world at large simply could not afford to coddle such a large portion of the population. Therefore, in general at that age you were well on your way to doing your adult life with the resources at your disposal to address consequences (at least, it was as good as it was ever going to get). By not being coddled, they were not spoiled and made more responsible decisions at a young age. I think not much has changed and given apt circumstances, a 14 year old could make sane decisions with respect to responsibility as a 20 year old.
Now, however, society is constructed in a way such that before 20 or so, there is nearly 0 chance someone could be independent, and therefore they must be tied to the parents for a longer time. This inevitably leads to more coddling, and people of the age of 14-15 are precluded from meaningfully being responsible above and beyond the purely artificial lines set by law. It's all-in-all a nicer life, but the price to pay is that the age of socially meaningful 'maturity' increases. Without direct responsibility of the monetary cost of their living, people are likely to be unable to comprehend the complete picture in a very real, personal way.
In fact I'd support raising the minimum age to get a lisence to 18, considering how many accidents are caused by young, irresponsible drivers. Yes, excellent idea, but I have a better one that works with your logic. Never let unexperienced drivers start driving! Those are always going to be the ones having those accidents. One can only be allowed to drive if they have been driving for a few years. Perfect.
That comes with responsibility and experience that most people simply don't have at that age. So your logic is that responsibility should not bestowed upon 14-year olds because.... they don't have that responsibility? That's begging the question.
I will say it isn't a matter of 'catching up' to other Windows software, this would be well above and beyond the current commercial windows application world, where you have to google in random ways to find the software you want, then run the software's installer (which inevitably each software thinks they are so special as to need an interactive installer).
As many have pointed out, you don't want a new 'packaging' system (i.e. msi replacement), you are looking for a sane repository system to architect (which may need something other than msi depending on msi functionality). It would be nice to run an application that knows absolutely you are looking for apps to install, that groups them in sane ways (someone mentioned tagging system, which could be a nice add to traditional repos), and when you click to install, it simply installs it without asking questions unless something really important needs be asked by the package.
A difficulty in Windows is that chosing where to install software is not as straightforward as *nix systems. In *nix world, you know you put certain bits in/usr/bin, others in/usr/lib, some in/usr/share, and the breakdown is obvious. Your storage is architected to accomodate this (in, say, a ZFS enabled world, your filesystem would simply grow as you added fixed storage), so you don't have to ask questions. Inevitably, software managed by such a system would likely not mesh well with traditional windows applications.
And finally, I would also like to mention that Cygwin has already started down this path, though they aim to be a more purist reproduction of a *nix environment (i.e. graphical apps require X to run, for the most part it 'pretends' to be in a unified filesystem space with everything in/usr/bin and such.). Of course, for the reasons pointed out above, this may be the only sane way of achieving these goals under the restriction of trying to base it on Windows.
See ubuntu default desktop for example. It periodically polls update server without the user intervening. When updates are noted, a little tray icon appears. Then the intuitive update-manager runs when they click, providing further tray icon/icons with any instructions to make sure the updates go into effect (i.e. reboot or restart firefox, etc...). Updates is easy and every modern desktop platform including OSX, MS, and most desktop-oriented distributions tackle it for the core product.
Now, the areas where Windows falls short. The core product is pretty small in the scheme of things. Only Microsoft first-party software is really managed in any meaningful way, and last I checked, only stuff that ships on the Windows install media and some downloads are part of that unified 'Windows update' (i.e. any MS games, office are handled separately). Every big third party software that wants to deal with updates intelligently, rolls their own. In the linux distribution world, the 'core' product is a much broader set of things, to the point that 99% of people can operate entirely within the context of what their default package repositories provide (office applications, games, even installers for promiment third party apps).
Let's presume this is an anomaly associated with the relatively low user-base (which to some extent it may be) and that if in Window's market share position, there would have to be more worries about software packaged outside the distribution. The beauty for both yum and apt is all that third party software has to do to get integrated to the distribution single update manager infrastructure is provide a repositories amenable to the target distributions and have their installer put a file in either yum's repos'd or sources.list.d for apt. This won't preclude third-parties from writing terribly packaged software that choses to roll their own crap, but it makes it more convenient to piggy-back on the distro update system than roll your own.
All this is putting aside the most obvious benefit, the searchable library of software you can install that you have yet to touch containing what is known to be packaged for your system. This is beyond updates, this is new software without the guesswork. In the Windows world, there is little guesswork (it probably is packaged for them), but there is still some (software that was written for Win9x, won't work in 2k-based systems, or would work but needs workarounds that could be described by the packaging software rather than documentation).
Desktop *nix systems by necessity developed far more advanced packaging and by extension package management systems than Windows has. Windows has to an extent banked on the application directory concept ('C:\Program Files\[AppName]', which I like in theory), but did it poorly (not really enforced/flexible enough, files in practice still end up all over the place). *nix systems developed an alternative index and had to absolutely rely on it since most everything ends up in/usr/bin,/usr/lib, et cetera. Rather than change the traditional layout to sanely accommodate application distinction, they went a path that ultimately was more flexible in many ways.
I enjoyed 4,6,7,9, and 10, for varying reasons, with fault to be found here and there.
FF4 to me was the first with a bit of depth to the story and characters. FF5 I found to revert to a more straightforward story with more flat characters. FF6 was quite epic with a deeper world and characters, but I found Kefka to be a weaker concept in terms of a villain. Also while the story was deeper, it still seemed too straightforward.
FF7 I feel is different and I loved it. They took some living planet philosophy to integrate some classical fantasy elements, but brought in some more dystopian sci-fi elements into it. I found Sephiroth to be a conceptually strong villain, as well as having more than two sides (Shin-Ra and Sephiroth/Jenova both 'bad guys', but bad guys that didn't work together). The general set of circumstances were to me refreshingly complex, allowing for more interesting in depth exploration of a story as well as a world. Most other games I could give a one-minute plot summary to someone who never played and feel I covered the important aspects, I could not with this game.
FF8 I thought reverted to a weak villain and overly straightforward... everything. It was much prettier and the world was still nicely designed, but the story and characters were lacking depth and too straightforward.
I won't claim 9 is deep or anything, but it was simple fun. It's a game I can't logically explain how, but I just liked it.
10 was just very fantastically designed. The visuals were strong and not afraid to be surreal as appropriate. The story was deeper than 8 and 9, with some surprises along the way. The world was very restrictive though, and most of the game holds you to a defined path to suit the story. Even when you get an airship and freedom, you never get to look at the world in a grander scale, instead having a point and click map to drop you down. That disappointed me.
11 I skipped, I've played MMORPGS and they are not my thing.
12 I played through, but didn't like. They were trying to copy MMORPGs too much for me, in terms of combat system. All the characters lack any semblance of depth, and the story is similarly straightforward. Visual design in general aimed too much for realism. Also, for the first time, the scope of everything seemed so limited. The entire story is set in a small part of a world, with constant reminders of bigger forces/places that you'll never see. It feels like a teaser for games that would cover that. I've liked that Square historically for each game set up a unique world and let gamers go at the whole of it and explore every facet as they pleased. Then toss out that world and move on to a new setting. Reusing the same world gets tiresome and artificially holding the world back to prevent that from happening is frustrating.
Hard core? It's only a compiler. Besides, there are only two architectures that matter, any more: x86 and x86-64. Yes, because the 17 billion dollar a year industry in Sparc/Power based systems doesn't exist.
Interesting you should hold up DVI as an example of the way things should be. HDMI on a core techincal level is a DVI-D connector with one additional functional pin (CEC which I've never seen used) arranged in a more compact form factor. The DRM used in HDMI started life and is implemented in some DVI devices. The audio being multiplexed in is a use of the digital data lines new to HDMI, but that is it. Hence why a DVI to HDMI cable is entirely passive (my Myth box uses a 7 dollar cable from its DVI port to get into sets HDMI port no problem).
It seems like a logical connector for widespread consumer use. The DVI connector is too bulky for some people, and in this capacity they only care about a single-link, digital only behavior, so they can ditch 8 pins and the key. I suppose the industry has established that for the most part latchless/screwless connectors seem to be the thing (S-video, RCA, even traditionally screwed coax connections in most end-user capacities are used with screwless connectors). I honestly can't complain, HDMI to me has been on par with USB, and the cables I use are light (I recognize there are Monster brand HDMI cables, but that's just foolishness).
However, the summary did seem like pretty silly phrasing. And on a hard, more technical issue with the subject matter, at least my state does not put magnetic stripes of any sort on the drivers license. When they did implement a machine-readable aspect to licenses in the last decade, they chose a 2D barcode instead of magnetic info. So the statement is not true for the set of licenses that come closest to being described as 'US drivers license'.
Go to the actual website of the company discussed, and you'll note they can only work in less than half the states.
To provide back up from your perspective, from the article and summary, it is clear this is done without coordination with the government at all, merely asking consumers to input the data so the data from readers spit out from happening to swipe a license can be correlated. In fact, the article mentions government officials telling people to be careful with this sort of thing.
I don't think relying upon potential victims carrying weapons of their own choice is a sound strategy (most people don't bother, so most of the time a situation comes up even if they had the option, chances are no one would be equipped to stop them).
Another thing I've heard suggested is that people should be *required* to be armed. Admittedly, I don't hear this argument out of many reasonable people, but it has come up. I can imagine that truly, incidents of mass-shootings would drop to nil, but incidents of one-off shootings in crimes of passion would go up way more than the lives saved from mass-shootings. Keep in mind that despite panic over VT, the example they readily evoke to demonstrate a pattern of increased shootings is Columbine, which happened 8 years ago. Other shootings occur, but examples of large-scale, indiscriminate attacks are few and far between. Over the past decade, there have been about 50 fatalities in indiscriminate mass-shootings in the US. Measures should be taken to correct it, but at the same time we must be careful that the 'solution' doesn't make things worse than the problem.
Probably some program to deputize, train, and arm some number of officials in areas of concern is potentially a prudent action. You have a known set of people to rely upon without indiscriminately putting guns in the hands of random people who may be prone to anger. Short of bombers, potential mass-killing attempts outside of schools are cut short if happening over a short period of time. Generally because police or private security companies that are armed are closer at hand, not because random people happened to be armed to stop it.
Have a Quadro FX 1000 (relatively ancient, but respectable). If I use a handful of windows, yes, it's fast, but once I start opening my typical workload of windows, craws to tens of FPS quickly on most operations.
Well, to one part of your argument, I know at least one fortune 100 company that has a fair amount of ubuntu in place. I also know that a fortune 1 company uses linux extensively, though I do not have specifics on what architecture. With HP, Sun, IBM, et. al taking linux Damn seriously, you can consider linux *real enterprrise sector stuff*. Linux is popular because it implements the fundamental design of Unix systems in a development situation that largely precludes any sort of vendor lock-in. You buy AIX on IBM System p, you have committed that as time goes by your investment is tied to buying from IBM again. You buy RedHat on Dell, and Dell disappoints you can go try HP in a future upgrade with minimal changes (one x86 box is just like another for most fundamental ways that matter). If Red Hat pisses you off, you go to Novell (not quite as non-impact, but certainly well within the realm of possibility, better than, say, AIX to HP-UX). Technical people love the unix-like architecture and the ready availability for whatever they wish. Business loves linux because of the vendor freedom and because the technical guys who love it and know it well are plentiful. Any interview I conduct, I ask about home usage and what they are looking into outside the boundaries of commercial experience. Inevitably the answers are more technically advanced and prove qualifications beyond their commercial work. Being freely available has not hurt. Solaris absolutely will need to cede control and authority so that more than one healthy commercial vendor sells and can support Solaris 100% independent of Sun's help. Making it supported on non Sun systems and x86 didn't help, making it as free-as-in-beer for most people didn't help, and making it more BSD-like has yet to make significant progress. If they GPL the codebase I don't think that in and of itself will help, but if some company or two succeeds in becoming a prominent solaris vendor who doesn't have to go to Sun for any partnership or anything, then it could begin to work, but they still have the momentum of linux which is not a situation easily overcome. I do think if they succeeded in making Solaris a prominent platform, their commercial distribution of it would probably not be that popular (I don't think on many fronts Sun 'gets it' on some of the technical things not right out-of-the-box with their software, the core is good and a good system can be built on it, but I don't think Sun is capable). Admittedly a small market share of a linux-scale market is much better than their total market-share of a small market.
Now, even if your statement was 100% accurate in every sense of the word, Nexenta's lack of development does *not* represent a stable and basically functional system. It represents a stale Nevada build. Sun has done many better builds since the last Nexenta release. A pity, Nexenta debian-ified Solaris enough to have the package management and general interface strategy be bearable (No matter how you slice it, Nevada's UI may have better options, but it's still ugly and misses a lot of the point in my opinion.
Well, for one, an administrative account may set up firewalling rules on a box to overrule attempts made by a normal account to open listening sockets (mitigate a number of attacks that rely on users running exploitable network apps or certain opportunistic attacks that listen for a queue to give a third party access). Performing a function along the lines of 'chown' for ports. The way many applications are written, unfortunately, implementing a more obviously chmod-like facility for ports in which the process impacted is made aware of the other layers policy, many existing applications would break.
A good example could be synergy. Let's say I'm a user interested in the program. I'm semi-lazy so I like the quicksynergy front end. If you ever use synergy, you know that it doesn't in and of itself bother with meaningful authentication or encryption. Also, while the daemon itself supports being explicit in terms of which IP interfaces to bind to, the quicksynergy frontend does not expose the relevant configuration options. So while I know how to make use of ssh to port forward and authenticate for me, out of the box I still may leave synergy hanging out accepting any connections on the IP network. Considering synergy could effectively be a means to do keylogging (if user accidently moves mouse to wrong place for example), this is highly dangerous. Now, my distribution being fairly restrictive had placed hard and fast firewall rules in place to only allow blessed applications access in, except on lo. If I wanted to shoot myself in the foot with synergy, I'd now have to jump through some hoops and hopefully in the process learn why it's a bad idea. There probably exist poorly designed but useful network daemons that don't even allow interface-specific binding, in which case firewall rules bridge the gap. You can't always shut down a process that does foolish things in terms of listening on sockets you don't like without configurability to get around it, sometimes you need that process to run and the network to be denied by a layer the process can't mess with and even is unable to absolutely confirm exists.
Yes, well-written applications should not do inappropriate things with listening sockets without the ability to lock it down. However, the world is full of not-so-well-written applications. The key is letting those apps think they are doing what they want with the firewall ruleset under the covers establishing the reality in ways the application cannot see or change. Good frontends for 99% of usage out there exist (OSX I believe makes it obvious when enabling a service it is also futzing some firewall rule to complement that, so it is intrinsically linked in the dialog most anyone will deal with).
This is one aspect where I disagree with Ubuntu philosophy. Ubuntu philosophy is along your lines (don't bother with iptables rules by default, they just get in the way and the user knows what they are doing). This seems incongruous with the whole mission of linux for the masses that Ubuntu is about.
There is *nothing* that special about online forms of expression from other venues. You cannot say people can harass any differently online than over a phone, for example. There's various functions available to take that action, but ultimately the legal system provides a process for dealing with it, and either online should be considered under that same process, or the process has to stop being applied to anything but face to face interactions, which you have no hard guaranteed way of keeping someone away.
I personally think people as a rule should take advantage of the facilities of the medium (call block, ignore, etc etc) as possible before resorting to the legal system. At the very least, it sends a clear warning shot to someone who may not be realizing a line is being crossed without springing potentially very damaging legal measures on them. It precludes the tie-up/excess tax money spent, and from the perspective of the 'victim', it's actually the least hastle (dealing with the authorities and working to see things to the end is a lot harder than '/ignore'.
The problem is when someone persistently overcomes such measures or crosses mediums to continually harass someone. For example using alternative, un-banned identities as identities get banned, or using payphones when a home number is blocked, etc. If on a personal level you cannot eliminate the harassment without compromising your own privileges to interact with other, non-offending people, a restraining order may be the viable option. Common sense is hard to codify, but in general people should know regardless of the interaction to tell someone to back off before crying harassment, and take convenient means before harsh ones, but in the end you cannot exempt one non-face-to-face medium more than another from the process.
On the story, I absolutely concur 'rape' is an inappropriate term for any such online activity, and harassment is exactly the term to describe what is said to have occurred. I think the 'victim' just doesn't want the perpetrator to be given the benefit of saying he ought to have beeen warned before more drastic measures (the authorities) were taken.
Slashdot Mirror
Fark forums, with text captions helpfully photoshopped at random.
It's called sticking with their current codebase and growing from that, being careful not to look at any code submitted post GPL3 of a given codebase. It's a pain and becomes more so over time, but realistically speaking I doubt many new core platform enhancements are really significant for Tivo's functionality. They already constructed a hardware platform and set of running processes such that things run that meet real-time-like needs, therefore hypothetical scheduling improvements buys them nothing. Filesystem/storage device drivers are similarly moot, since they already work, and they don't intend on supporting more complex configurations that such featurs could help with. The fundamental utilities meet their needs today. The open network ports they have are likely controlled by their proprietary software, or if they do have some such software with a vulnerability fixed only in the GPL3 tree, then undoubtedly they could find an alternative project that didn't go GPL3 (even if it is a commercial product) to use.
If I had to make a decision with goals like Tivo's in mind, I probably would have gone for a BSD codebase. BSD explicitly aims for what the makers of Tivo would be comfortable with. Doesn't preclude them from giving back, but doesn't hold the accountable for not giving back either. Think GPL is great for the community, but a company looking to for all intents and purposes exploit free software developers may not be able to deal with GPL, and BSD developers welcome the opportunity to get their code wherever, so long as they get credit where it is due.
They aren't implying that either math ability or long ring fingers *cause* the other, simply that there is some apparent statistical correlation. The put forth a hypothesis on something they believe would be a common cause for both situations, but do not say they cause one another.
Is people insisting on high-performance RAID knowing full well that the system will only ever do NFS/SMB serving, not running any more complex processes locally, and accessing the disks via a single gigabit link. Or assuming absolutely that a RAID controller that is true hardware is guaranteed to be faster. I have seen RAID controllers where, true, the processor usage/throughput was technically lower (meaning the already largely idle cpus were more idle), the hardware engine on the card would hit its cap in performance well before the processor would hit any cap. Basically, if your criteria is 'must be hardware RAID', without any specific metrics and without researching the quantified performance numbers for the cards being looked into, then I think software RAID is probably really the answer.
Adding to your point about differing sets of tools, if you have an 8-year old server the raid controller goes out on, your chances of finding a compatible controller that can understand and import that array is slim, so you could have to rely unnecessarily on your backups just because your hardware vendor doesn't support you anymore. Hardware RAID has a lot of disadvantages.
It's been a long time, but the Windows 2000 server I used to admin back in the day, software raid was integrated into the 'disk management' MMC plugin. I believe last I checked on a non-'server' MS install (2000 workstation), software raid beyond simple mirroring was not available (at least I couldn't find the same way to enable it I did on the server OS).
This was rather vague, but I know MS does this as well (that's one of the installs where I had to rebuild the array from it thinking two drives went bad concurrently). I'm sure google can help in more detail (it's obviously been years since I had to be a Windows admin, never even touched Server 2003).
Hm, guess I should have more specifically said didn't see the point for me. Most all of those bullet points can be implemented at the OS layer in a cross-platform manner using an OS without draconian licensing for client access count. However, admittedly, you must have a perhaps more competent admin as implementing some of these features is not as trivial as what the NAS vendors may do for you.
The one thing that stands out as lacking would be a true versioned copy-on-write system. Currently everything I mess with is contigent on point-in-time snapshotting, if you make two changes to a file between snapshots, that one change is lost.
Avoiding single point of failure is about more than the cables between systems. Most architected SAN solutions are paranoid about even solid-state component failure. I.e. a RAID controller determines it has bad cache memory. In a typical SAN architecture, the controller notes the presence of a peer controller, throws up its hands, says replace me, and the other controller takes over, while the other controller is presumably hot swapped. If your controller with direct connected drives fails, well, that was your single point of failure. Your server suffers a catastrophic failure (PCI fault, processor fault, uncorrectable ECC), you have lost access to your storage. If you implement anything fancier (i.e. with multiple systems, talking to multiple controllers each with multiple paths to each individual drive), then by definition it becomes a SAN. Feel free to replace the FC fabric with iSCSI, or whatever commonly supported block-device-oriented strategy you want, it's still a SAN. Feel free to run ZFS on top of a SAN, though perhaps only in an active-passive way.
BTW, in many many ungodly amounts of explicit storage testing for data miscompare situations (why you would need above-block-layer checksuming), I have yet to see a single instance not caught by individual hard drive ECC mechanisms. I consider ZFS' checksumming nifty and good for demos involving dd and random data with an array member, but in real-world situations, it is largely redundant. Checksumming is done in lower levels transparently to the user, it's more of an assumed must-have than a 'hey look, we checksum!'. The checksumming would only catch errors that probably are obvious and caught before they ever reach ZFS. Now one thing I would like to see something do is upon seeing a bad block reported from a lower level, automatically go back and attempt to write back that one block of data based on other array member data. Bad block reallocation is nice for writes, but I have seen one array where by the time one bad, unrecoverable block was detected, other members of the array also had unrecoverable blocks in other places. All the data was still there, but the array wanted N-1 100% good members for the entire data set, instead of N-1 100% good members on a block-by-block basis. If instead of kicking out of the array, it would have rewritten the data it could then interpolate from other members, just a disaster would be averted (just monitor the SMART reported bad block reallocation count.)
Depending on the scale and application of the fileserver, generic OS provided software RAID will probably be more robust/recoverable than hardware RAID, without an unacceptable degradation in performance. I have, for example, an Adaptec 2410SA RAID adapter. The performance is not compelling, but the deal breaker for me is the card had on occasion, lost it's mind on unclean system reset. The drives were out of the array and that adapter offered no 'put together and assume it was a RAID-5 with this layout before, just sync the parity', so the data was non-trivially unavailable. With linux software RAID in particular (and the one time with Windows software RAID that I had to maintain as well), the tools in terms of what conditions can be recovered from and how it is to do are pretty smart and flexible. Both architectures I saw systems that decided (wrongly so) to put multiple drives on a single IDE channel and wrap in software RAID. A drive would effectively knock out accessibility for the other and the array would lose two members. For many hardware controllers, that would be 'the end'. Software RAID I was able to say 'assemble this array and assume I know what I'm talking about', and recover data without resorting to other backups which were inconvenient, or non-existant.
Some situations, you have particular hard throughput requirements you can quantify, in which case you may have little choice. Keep in mind if just doing simple file storage sharing (NFS/SMB) primarily over a single gigabit link or worse, you have really nothing much to gain from a high-performance internal subsystem. If you have local-storage for a high TPC database system or some disk intensive modeling or something, that's where you really start thinking about hardware controllers, IMHO,
Distributions like gentoo subscribe to a philosophy that goes down the path you fear, leave the decisions to upstream as to how to go 99% of the time. This philosophy has a place, but as you have pointed out, what upstream considers 'minor revisions' can vary greatly and never preclude feature behavior changes. Even if you simply tracked GLSA, more often than not the 'answer' is to update to a new revision of the package in question which is not precluded from new features being implemented or old ones changed. If you run Gentoo, you should know what you are getting into and what you are getting in exchange for that concession.
ZFS does not obsolete NAS/SAN. However, for many many many instances, DIY fileservers have been more appropriate than SAN or NAS situations for many concepts long before ZFS came along, and ZFS has done little to change that situation (though adminning ZFS is more straightfoward and in some ways more efficient than the traditional, disparate strategies to achieve the same thing).
I haven't gotten the point of standalone NAS boxes. They always were not fundamentally different from a traditional server, but with a premium price attached. I may not have seen the high-end stuff, howerver.
SAN is an entirely different situation all together. You could have ZFS implemented on top of a SAN-backed block device (though I don't know if ZFS has any provisions to make this desirable). SAN is about solid performance to a number of nodes with extreme availability in mind. Most of the time in a SAN, every hard drive would be a member of a RAID, with each drive having two paths to power and to two RAID controllers in the chassis, each RAID controller having two uplinks to either two hosts or two FC switches, and each host either having two uplinks to the two different controllers or to two FC switches. Obviously, this gets pricey for good reason which may or may not be applicable to your purposes (frequently not), but the point of most SAN situations is no single-point of failure. For simple operation of multiple nodes on a common block device, HA is used to decide which single node owns/mounts any FS at a given time. Other times, a SAN filesystem like GPFS is used to mount the block device concurrenlty among many nodes, for active-active behavior.
For the common case of 'decently' availble storage, a robust server with RAID arrays has for a long time been more appropriate for the majority of uses.
I concur in general that the concept of an extended adolescence is an artifact of modern society, but at the same time it may be a mistake to dismiss something that has evolved in society as merely artificial and therefore safe to put aside. In "ye olde tymes" life was simpler. By no means easier or safer, in fact very much the opposite, but simple. By 13/14, you had realistically learned everything you would need to operate successfully in 98% of the adult society. Children grew up young because the world at large simply could not afford to coddle such a large portion of the population. Therefore, in general at that age you were well on your way to doing your adult life with the resources at your disposal to address consequences (at least, it was as good as it was ever going to get). By not being coddled, they were not spoiled and made more responsible decisions at a young age. I think not much has changed and given apt circumstances, a 14 year old could make sane decisions with respect to responsibility as a 20 year old.
Now, however, society is constructed in a way such that before 20 or so, there is nearly 0 chance someone could be independent, and therefore they must be tied to the parents for a longer time. This inevitably leads to more coddling, and people of the age of 14-15 are precluded from meaningfully being responsible above and beyond the purely artificial lines set by law. It's all-in-all a nicer life, but the price to pay is that the age of socially meaningful 'maturity' increases. Without direct responsibility of the monetary cost of their living, people are likely to be unable to comprehend the complete picture in a very real, personal way.
I will say it isn't a matter of 'catching up' to other Windows software, this would be well above and beyond the current commercial windows application world, where you have to google in random ways to find the software you want, then run the software's installer (which inevitably each software thinks they are so special as to need an interactive installer).
/usr/bin, others in /usr/lib, some in /usr/share, and the breakdown is obvious. Your storage is architected to accomodate this (in, say, a ZFS enabled world, your filesystem would simply grow as you added fixed storage), so you don't have to ask questions. Inevitably, software managed by such a system would likely not mesh well with traditional windows applications.
/usr/bin and such.). Of course, for the reasons pointed out above, this may be the only sane way of achieving these goals under the restriction of trying to base it on Windows.
As many have pointed out, you don't want a new 'packaging' system (i.e. msi replacement), you are looking for a sane repository system to architect (which may need something other than msi depending on msi functionality). It would be nice to run an application that knows absolutely you are looking for apps to install, that groups them in sane ways (someone mentioned tagging system, which could be a nice add to traditional repos), and when you click to install, it simply installs it without asking questions unless something really important needs be asked by the package.
A difficulty in Windows is that chosing where to install software is not as straightforward as *nix systems. In *nix world, you know you put certain bits in
And finally, I would also like to mention that Cygwin has already started down this path, though they aim to be a more purist reproduction of a *nix environment (i.e. graphical apps require X to run, for the most part it 'pretends' to be in a unified filesystem space with everything in
See ubuntu default desktop for example. It periodically polls update server without the user intervening. When updates are noted, a little tray icon appears. Then the intuitive update-manager runs when they click, providing further tray icon/icons with any instructions to make sure the updates go into effect (i.e. reboot or restart firefox, etc...). Updates is easy and every modern desktop platform including OSX, MS, and most desktop-oriented distributions tackle it for the core product.
/usr/bin, /usr/lib, et cetera. Rather than change the traditional layout to sanely accommodate application distinction, they went a path that ultimately was more flexible in many ways.
Now, the areas where Windows falls short. The core product is pretty small in the scheme of things. Only Microsoft first-party software is really managed in any meaningful way, and last I checked, only stuff that ships on the Windows install media and some downloads are part of that unified 'Windows update' (i.e. any MS games, office are handled separately). Every big third party software that wants to deal with updates intelligently, rolls their own. In the linux distribution world, the 'core' product is a much broader set of things, to the point that 99% of people can operate entirely within the context of what their default package repositories provide (office applications, games, even installers for promiment third party apps).
Let's presume this is an anomaly associated with the relatively low user-base (which to some extent it may be) and that if in Window's market share position, there would have to be more worries about software packaged outside the distribution. The beauty for both yum and apt is all that third party software has to do to get integrated to the distribution single update manager infrastructure is provide a repositories amenable to the target distributions and have their installer put a file in either yum's repos'd or sources.list.d for apt. This won't preclude third-parties from writing terribly packaged software that choses to roll their own crap, but it makes it more convenient to piggy-back on the distro update system than roll your own.
All this is putting aside the most obvious benefit, the searchable library of software you can install that you have yet to touch containing what is known to be packaged for your system. This is beyond updates, this is new software without the guesswork. In the Windows world, there is little guesswork (it probably is packaged for them), but there is still some (software that was written for Win9x, won't work in 2k-based systems, or would work but needs workarounds that could be described by the packaging software rather than documentation).
Desktop *nix systems by necessity developed far more advanced packaging and by extension package management systems than Windows has. Windows has to an extent banked on the application directory concept ('C:\Program Files\[AppName]', which I like in theory), but did it poorly (not really enforced/flexible enough, files in practice still end up all over the place). *nix systems developed an alternative index and had to absolutely rely on it since most everything ends up in
I enjoyed 4,6,7,9, and 10, for varying reasons, with fault to be found here and there.
FF4 to me was the first with a bit of depth to the story and characters.
FF5 I found to revert to a more straightforward story with more flat characters.
FF6 was quite epic with a deeper world and characters, but I found Kefka to be a weaker concept in terms of a villain. Also while the story was deeper, it still seemed too straightforward.
FF7 I feel is different and I loved it. They took some living planet philosophy to integrate some classical fantasy elements, but brought in some more dystopian sci-fi elements into it. I found Sephiroth to be a conceptually strong villain, as well as having more than two sides (Shin-Ra and Sephiroth/Jenova both 'bad guys', but bad guys that didn't work together). The general set of circumstances were to me refreshingly complex, allowing for more interesting in depth exploration of a story as well as a world. Most other games I could give a one-minute plot summary to someone who never played and feel I covered the important aspects, I could not with this game.
FF8 I thought reverted to a weak villain and overly straightforward... everything. It was much prettier and the world was still nicely designed, but the story and characters were lacking depth and too straightforward.
I won't claim 9 is deep or anything, but it was simple fun. It's a game I can't logically explain how, but I just liked it.
10 was just very fantastically designed. The visuals were strong and not afraid to be surreal as appropriate. The story was deeper than 8 and 9, with some surprises along the way. The world was very restrictive though, and most of the game holds you to a defined path to suit the story. Even when you get an airship and freedom, you never get to look at the world in a grander scale, instead having a point and click map to drop you down. That disappointed me.
11 I skipped, I've played MMORPGS and they are not my thing.
12 I played through, but didn't like. They were trying to copy MMORPGs too much for me, in terms of combat system. All the characters lack any semblance of depth, and the story is similarly straightforward. Visual design in general aimed too much for realism. Also, for the first time, the scope of everything seemed so limited. The entire story is set in a small part of a world, with constant reminders of bigger forces/places that you'll never see. It feels like a teaser for games that would cover that. I've liked that Square historically for each game set up a unique world and let gamers go at the whole of it and explore every facet as they pleased. Then toss out that world and move on to a new setting. Reusing the same world gets tiresome and artificially holding the world back to prevent that from happening is frustrating.
Interesting you should hold up DVI as an example of the way things should be. HDMI on a core techincal level is a DVI-D connector with one additional functional pin (CEC which I've never seen used) arranged in a more compact form factor. The DRM used in HDMI started life and is implemented in some DVI devices. The audio being multiplexed in is a use of the digital data lines new to HDMI, but that is it. Hence why a DVI to HDMI cable is entirely passive (my Myth box uses a 7 dollar cable from its DVI port to get into sets HDMI port no problem).
It seems like a logical connector for widespread consumer use. The DVI connector is too bulky for some people, and in this capacity they only care about a single-link, digital only behavior, so they can ditch 8 pins and the key. I suppose the industry has established that for the most part latchless/screwless connectors seem to be the thing (S-video, RCA, even traditionally screwed coax connections in most end-user capacities are used with screwless connectors). I honestly can't complain, HDMI to me has been on par with USB, and the cables I use are light (I recognize there are Monster brand HDMI cables, but that's just foolishness).
However, the summary did seem like pretty silly phrasing. And on a hard, more technical issue with the subject matter, at least my state does not put magnetic stripes of any sort on the drivers license. When they did implement a machine-readable aspect to licenses in the last decade, they chose a 2D barcode instead of magnetic info. So the statement is not true for the set of licenses that come closest to being described as 'US drivers license'.
Go to the actual website of the company discussed, and you'll note they can only work in less than half the states.
To provide back up from your perspective, from the article and summary, it is clear this is done without coordination with the government at all, merely asking consumers to input the data so the data from readers spit out from happening to swipe a license can be correlated. In fact, the article mentions government officials telling people to be careful with this sort of thing.
I don't think relying upon potential victims carrying weapons of their own choice is a sound strategy (most people don't bother, so most of the time a situation comes up even if they had the option, chances are no one would be equipped to stop them).
Another thing I've heard suggested is that people should be *required* to be armed. Admittedly, I don't hear this argument out of many reasonable people, but it has come up. I can imagine that truly, incidents of mass-shootings would drop to nil, but incidents of one-off shootings in crimes of passion would go up way more than the lives saved from mass-shootings. Keep in mind that despite panic over VT, the example they readily evoke to demonstrate a pattern of increased shootings is Columbine, which happened 8 years ago. Other shootings occur, but examples of large-scale, indiscriminate attacks are few and far between. Over the past decade, there have been about 50 fatalities in indiscriminate mass-shootings in the US. Measures should be taken to correct it, but at the same time we must be careful that the 'solution' doesn't make things worse than the problem.
Probably some program to deputize, train, and arm some number of officials in areas of concern is potentially a prudent action. You have a known set of people to rely upon without indiscriminately putting guns in the hands of random people who may be prone to anger. Short of bombers, potential mass-killing attempts outside of schools are cut short if happening over a short period of time. Generally because police or private security companies that are armed are closer at hand, not because random people happened to be armed to stop it.
Have a Quadro FX 1000 (relatively ancient, but respectable). If I use a handful of windows, yes, it's fast, but once I start opening my typical workload of windows, craws to tens of FPS quickly on most operations.
That IPv4 is not intelligently designed?
Well, to one part of your argument, I know at least one fortune 100 company that has a fair amount of ubuntu in place. I also know that a fortune 1 company uses linux extensively, though I do not have specifics on what architecture. With HP, Sun, IBM, et. al taking linux Damn seriously, you can consider linux *real enterprrise sector stuff*. Linux is popular because it implements the fundamental design of Unix systems in a development situation that largely precludes any sort of vendor lock-in. You buy AIX on IBM System p, you have committed that as time goes by your investment is tied to buying from IBM again. You buy RedHat on Dell, and Dell disappoints you can go try HP in a future upgrade with minimal changes (one x86 box is just like another for most fundamental ways that matter). If Red Hat pisses you off, you go to Novell (not quite as non-impact, but certainly well within the realm of possibility, better than, say, AIX to HP-UX). Technical people love the unix-like architecture and the ready availability for whatever they wish. Business loves linux because of the vendor freedom and because the technical guys who love it and know it well are plentiful. Any interview I conduct, I ask about home usage and what they are looking into outside the boundaries of commercial experience. Inevitably the answers are more technically advanced and prove qualifications beyond their commercial work. Being freely available has not hurt. Solaris absolutely will need to cede control and authority so that more than one healthy commercial vendor sells and can support Solaris 100% independent of Sun's help. Making it supported on non Sun systems and x86 didn't help, making it as free-as-in-beer for most people didn't help, and making it more BSD-like has yet to make significant progress. If they GPL the codebase I don't think that in and of itself will help, but if some company or two succeeds in becoming a prominent solaris vendor who doesn't have to go to Sun for any partnership or anything, then it could begin to work, but they still have the momentum of linux which is not a situation easily overcome. I do think if they succeeded in making Solaris a prominent platform, their commercial distribution of it would probably not be that popular (I don't think on many fronts Sun 'gets it' on some of the technical things not right out-of-the-box with their software, the core is good and a good system can be built on it, but I don't think Sun is capable). Admittedly a small market share of a linux-scale market is much better than their total market-share of a small market.
Now, even if your statement was 100% accurate in every sense of the word, Nexenta's lack of development does *not* represent a stable and basically functional system. It represents a stale Nevada build. Sun has done many better builds since the last Nexenta release. A pity, Nexenta debian-ified Solaris enough to have the package management and general interface strategy be bearable (No matter how you slice it, Nevada's UI may have better options, but it's still ugly and misses a lot of the point in my opinion.
Well, for one, an administrative account may set up firewalling rules on a box to overrule attempts made by a normal account to open listening sockets (mitigate a number of attacks that rely on users running exploitable network apps or certain opportunistic attacks that listen for a queue to give a third party access). Performing a function along the lines of 'chown' for ports. The way many applications are written, unfortunately, implementing a more obviously chmod-like facility for ports in which the process impacted is made aware of the other layers policy, many existing applications would break.
A good example could be synergy. Let's say I'm a user interested in the program. I'm semi-lazy so I like the quicksynergy front end. If you ever use synergy, you know that it doesn't in and of itself bother with meaningful authentication or encryption. Also, while the daemon itself supports being explicit in terms of which IP interfaces to bind to, the quicksynergy frontend does not expose the relevant configuration options. So while I know how to make use of ssh to port forward and authenticate for me, out of the box I still may leave synergy hanging out accepting any connections on the IP network. Considering synergy could effectively be a means to do keylogging (if user accidently moves mouse to wrong place for example), this is highly dangerous. Now, my distribution being fairly restrictive had placed hard and fast firewall rules in place to only allow blessed applications access in, except on lo. If I wanted to shoot myself in the foot with synergy, I'd now have to jump through some hoops and hopefully in the process learn why it's a bad idea. There probably exist poorly designed but useful network daemons that don't even allow interface-specific binding, in which case firewall rules bridge the gap. You can't always shut down a process that does foolish things in terms of listening on sockets you don't like without configurability to get around it, sometimes you need that process to run and the network to be denied by a layer the process can't mess with and even is unable to absolutely confirm exists.
Yes, well-written applications should not do inappropriate things with listening sockets without the ability to lock it down. However, the world is full of not-so-well-written applications. The key is letting those apps think they are doing what they want with the firewall ruleset under the covers establishing the reality in ways the application cannot see or change. Good frontends for 99% of usage out there exist (OSX I believe makes it obvious when enabling a service it is also futzing some firewall rule to complement that, so it is intrinsically linked in the dialog most anyone will deal with).
This is one aspect where I disagree with Ubuntu philosophy. Ubuntu philosophy is along your lines (don't bother with iptables rules by default, they just get in the way and the user knows what they are doing). This seems incongruous with the whole mission of linux for the masses that Ubuntu is about.
There is *nothing* that special about online forms of expression from other venues. You cannot say people can harass any differently online than over a phone, for example. There's various functions available to take that action, but ultimately the legal system provides a process for dealing with it, and either online should be considered under that same process, or the process has to stop being applied to anything but face to face interactions, which you have no hard guaranteed way of keeping someone away.
I personally think people as a rule should take advantage of the facilities of the medium (call block, ignore, etc etc) as possible before resorting to the legal system. At the very least, it sends a clear warning shot to someone who may not be realizing a line is being crossed without springing potentially very damaging legal measures on them. It precludes the tie-up/excess tax money spent, and from the perspective of the 'victim', it's actually the least hastle (dealing with the authorities and working to see things to the end is a lot harder than '/ignore'.
The problem is when someone persistently overcomes such measures or crosses mediums to continually harass someone. For example using alternative, un-banned identities as identities get banned, or using payphones when a home number is blocked, etc. If on a personal level you cannot eliminate the harassment without compromising your own privileges to interact with other, non-offending people, a restraining order may be the viable option. Common sense is hard to codify, but in general people should know regardless of the interaction to tell someone to back off before crying harassment, and take convenient means before harsh ones, but in the end you cannot exempt one non-face-to-face medium more than another from the process.
On the story, I absolutely concur 'rape' is an inappropriate term for any such online activity, and harassment is exactly the term to describe what is said to have occurred. I think the 'victim' just doesn't want the perpetrator to be given the benefit of saying he ought to have beeen warned before more drastic measures (the authorities) were taken.
God posts to slashdot, but didn't even register an account?