The real question, however, is will the.NET framework on Linux be good enough so that people will actually want to use it?
No, that's not the real question. The.NET framework that is being implemented as part of Mono is not the preferred way of writing GUI applications, it's a compatibility library.
The preferred way of writing GUI apps on Linux in C# is using Gtk# and Gnome. And we already know that that is good enough for people to want to use it.
It's a more established framework and a lot more cross-platform.
Well, first of all, the only full implementations of Java are proprietary. If you use any of the open ones, you miss out on huge chunks of functionality (e.g., there is no open source Swing implementation). Furthermore, Sun's patents and license agreements for Java seem to preclude full open source implementations.
Secondly, I don't want cross-platform support. Sun is making too many compromises in order to force cross platform. It really doesn't matter to me whether my Java application runs well on Windows if it doesn't run well on Linux. C# makes it easy to use platform specific libraries, and that's exactly what I want.
But he doesn't think it's a good thing because then everyone - even on Linux, even on embedded devices - will use.NET and whenever Microsoft feels like it (i.e. when Mono/dotGNU really have a market share) they can enfore their patents and - whooops, Mono/dotGnu have vanished.
Microsoft has a patent on.NET. If they chose to exercise that and if it were valid (a big if), then Mono would have to drop.NET compatibility. The effect of that would be minor since most Mono software doesn't use.NET.
Note that, in comparison, the situation for Java is far worse: Sun has dozens of Java-related patents, real patents that, unlike the Microsoft.NET patent, will likely have no problems sticking if Sun decides to exercise them. Note also that there is no complete open source implementation of Java.
Yes, it would be better if the.NET patent just went away. But between an open source platform (Mono) that is largely legally unencumbered except for a Windows-compatibility library that I don't use (.NET), and a proprietary platform (Java) whose core functionality is covered by Sun patents, Mono seems like the safer alternative. Not perfect, but nothing in this world ever is.
C# is a decent language, and unlike Java, it has an open standard. Why not implement it? That's the way we got C and C++: the GNU project decided to implement an existing standard.
It sounds to me like you are confusing the language and the platform. Yes, in addition to implementing C#, Mono is also copying the.NET platform, but you don't have to use.NET in order to use Mono. In fact, you probably shouldn't: Gtk# and other Mono-specific libraries are far nicer than the.NET stuff..NET compatibility is only there as an additional offering for those who need it and want to migrate off of Microsoft's implementation.
In fact, one of the nice things about C# compared with Java is that the C# guys are not religiously cross-platform. You are, in fact, encouraged to use C# the way you might use C and C++: to call the best libraries your platform has to offer. Think of C# just as a better C++; (thankfully) it isn't trying to do what Java is trying to do.
Windows.Forms is part of Microsoft's.NET Framework, and GTK# is Mono's extension to the.NET Framework to allow more portable.NET graphics.
Gtk# is not an extension to the.NET framework. Gtk# is a completely different library and toolkit from.NET. Gtk# is a C# language binding of the Gtk+ library. You don't need to know.NET in order to use Gtk#.
then you'd be extending.NET just the same as Mono is.
Mono is a project that comprises many subprojects. One of those subprojects is.NET compatibility. But if that subproject were dropped from Mono, you'd still be left with a vibrant, useful project. It is therefore wrong to talk of Mono as "extending.NET" as if.NET was the foundation of everything Mono does.
Mono feeds off of the various Linux GUI libararies in order to implement the windowing requirements for.NET.
Most GUI apps in Mono are written using Gtk#, through non-.NET APIs.
Mono offers no improvements to.NET as a Framework.
You just have no idea what you are talking about. Mono offers most of Gnome and Gtk+ directly to C# programmers, as well as many other open source libraries that people already know from C and C++ programming.
They are also nowhere near completion of implementing the entire Framework.
And they don't have to be because completing its implementation of.NET is not necessary for making Mono a great programming environment, since Mono has its own set of APIs, APIs that, incidentally, are very easy to use for Gnome and Linux programmers because they are the standard APIs they are alsoread using.
In fact, I wish Mono would just drop.NET compatibility altogether: it's superfluous and a waste of time. ECMA C# with standard Linux libraries is a better choice and it's already here.
So how is it not a knock off? Because it runs on Linux?
Mono is a huge project that encompasses several distinct parts:
A C# compiler and CLR runtime.
A large set of open source APIs and libraries, like Gtk#.
A compatible implementation of the.NET APIs.
Item 1 is the implementation of a language standard; if it is a "knockoff", then so are GNU C and C++.
Item 2 is its own thing, something nobody else has for C#.
Items 1 and 2 are the most important ones for the Mono project.
Item 3 is indeed a re-implementation of a closed source, non-standard API. If you want to call that portion of Mono a "knock-off", then so be it. Keep in mind, however, that most of Microsoft's products are knock-offs as well, as are a lot of other open source projects, so I don't really see what's wrong with being a "knock off", in particular when a project like Mono also has a complete and separate set of APIs.
Mono is simply.NET for non-Windows environments. Its a.NET Knock off.
No, that is completely and absolutely false..NET is only a small part of Mono, and a part that many Mono users probably wouldn't even miss.
Re:and the problem would be what, exactly?
on
Beyond Pay?
·
· Score: 1
On the other side of the coin, I can't keep a nanny or cleaning lady twelve hours a day for a week without any extra compensation under threat of termination.
Of course, you can. She would probably just quit her job rather than put up with it. And you have the same choice with your employer: either quit or put up with it.
Object-oriented programming allowed developers to create industrial software that is far more complex than what functional programming allowed.
She means "procedural programming". It's pretty amazing that a "senior IT architect" who makes pronouncements on the future of programming doesn't know the difference between "functional programming" and "procedural programming".
Q: So, your basic thesis is that programming constructs should be more intuitive to developers, and more closely simulate and resemble the real world. That would enable developers to write software with fewer bugs, right? A: Exactly.
What are computers trying to do in the real world? They are trying to solve problems, not simulate problems. The solution to a problem is completely different from its simulation. Yes, the simulation is simpler to implement, but it doesn't solve the problem.
Smalltalk (incidentally, a much better designed language than Java) had the same underlying idea, and it didn't catch on because programming really doesn't work that way. Smalltalk turned out to be a decent programming language but no silver bullet. Unlike Java, Smalltalk was extensible enough that whatever abstractions it was missing in the base language could be added by users.
But expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions -- like processes and conditions -- is only half of the arsenal in the war on complexity.
I see: adding dozens of complex, additional abstractions that can all interact in unpredictable ways is supposed to make programming simpler. PL/I and Ada, here we come.
Enormous productivity gains remain to be uncovered and difficult problems are yet to be solved.
Yes, but evidently not by Sun, since Sun clearly has no idea what they are doing.
From the description, it sounds like if you have multiple pages with different signatures, you get back the OR of their bits. That means you have to ensure that the pages are scanned one-by-one, and at that point, you might as well use an optical barcode anyway.
and the problem would be what, exactly?
on
Beyond Pay?
·
· Score: 2, Insightful
Examples of this include the company forcing employees to put in extra (unpaid) hours, with the implicit/explicit threat of loosing the job if they don't, to actual personal harassment in the work place by management staff
You should look at your employment contract. There are some employment contracts under which you never get paid overtime, and there are others in which you are. In either case, the employer can fire you if he isn't satisfied with your performance. Maybe the fact that your employer tells you to work overtime is a last opportunity he is giving you for making up work you should have been getting done during working hours if you had been reasonably effective (and not been posting on Slashdot).
My experience is that even in cases where the employee is completely right, it is impossible for her to win the case, given current employment law."
Of course, and why not? There is a small set of things your employer cannot fire you (e.g., your race). Anything else is fair game. After all, you yourself wouldn't want to be forced to keep employing a nanny or cleaning lady if you don't like the way she is performing. Why should your employer be forced to do the equivalent, then?
C# is a nice language, it's free, open, and standardized, and it's good that there are many implementations of it. All those other points don't matter.
What MS does or doesn't do with C# is their business. And if.NET remains proprietary, all the better as far as I'm concerned: I like the language, not MS libraries.
An old adage that governments would be well-served to heed is: You get what you pay for.
Quite right.
When you rely on free or low-cost products, you often get the shaft, and that, in my opinion, is exactly what governments are on track to get.'
Well, then open source shouldn't be a concern. Open source software isn't "free" as in "no cost". Quite to the contrary: open source software may well require you to pay considerably more for skilled developers and skilled system managers to adapt and deploy it. And in return for doing so, you get better quality software and you lower your overall operating costs. The fact that open source also happens to save you licensing fees is icing on the cake.
That is in sharp contrast to a lot of commercial software that promises to be so trivial that even an untrained monkey can use it. Of course, it doesn't actually deliver on those promises--many problems are just intrinsically hard and no matter how many dialog boxes and help files you add, people still won't be able to use it--but it gives the appearance of doing so, and that is arguably far worse.
In different words, the commercial software vendors are in the tradition of snake oil salesmen and miracle healers, who charge a huge amount of money for their miracle cures and try to keep charging you. Open source developers, in contrast, are more often in the category of skilled medical professionals: you hire them, you pay them a good salary, they solve your problem, and then they go on to the next patient.
Technically, ePalm sounds like it might be a good thing. SmartEiffel, which it is based on, can generate quite compact native code even from large, object-oriented libraries because it performs global optimizations; that makes it a better choice than VM-based systems like Java or.NET. Furthermore, PalmOS doesn't isolate programs very well from one another, so a language like Eiffel, with built-in garbage collection and error checking, has a real advantage over C.
Still, SuperWaba probably fills that niche well enough and Palm handhelds are getting powerful enough so that the advantages of ePalm won't be big enough to let it catch on.
Except that GPL Qt is available for the Mac. So, it is functionally no different than programming something in pure Qt for Linux, at least with regards to promoting their 'commercial' and 'proprietary' product.
Yes, you are quite right: it is very similar.
Unless you are also against all Qt programming in Linux? Or are you fully against free software on the Mac?
I don't know what you mean by "being against it". I think Troll Tech had a mediocre toolkit that only succeeded because of their licensing gimmicks and they have taken unfair advantage of gullible open source developers in order to succeed. When you develop a good application for Qt or Macintosh, you are giving those two companies a huge, free gift. Why would you want to do that when you could instead create software on/for open source platforms that you yourself have full control over?
So, I think it's stupid for you to develop open source software in Qt or for Macintosh. But you have a right to be stupid, so in that sense, I'm not "against it", I'm just pointing out your stupidity.
Studies like this one may lead to smarter urban-growth strategies in the future.
I really doubt it. There are much bigger, more immediate problems with our "urban-growth strategies" than that (pollution, traffic, etc.), problems whose solution would result in enormous and immediate benefits to every resident. Since we don't manage to solve those, something as abstract and without direct impact as the use of fertile land to build cities on will lead to anything.
Clearly your utility is equivalent to your economic gain.
When developing software whose purpose is to promote other companies' commercial platforms, you bet it is. That kind of thing, I expect to get paid for.
For many other kinds of software development, I develop and share it freely. That has many non-monetary benefits. But those don't apply in this case.
GTK may be more efficient for *NIX/X11 development, but it doesn't touch Qt in the cross platform arena.
No, but Gtk+ runs natively when you run it on the Mac because Apple now has a pretty good official X11 server for OS X, and they keep improving the integration of it into the desktop.
Sorry, but with this logic, there would never be any Linux or GNU software.
No: Linux and GNU software is open source software for an open source platform. Even when GNU software was originally developed, the fact that it ran on SunOS was viewed as a temporary compromise, with the long term goal of replacing SunOS with something open source.
The Qt/Mac competition promotes the creation of software for a proprietary toolkit on a proprietary platform and has no intention of replacing either of those proprietary tools with anything free.
Now getting something as frivolous as Apple G5 is nice, since most rational people realise that they don't really need a G5 and so won't buy it.
I don't see anything "frivolous" about a G5--its performance is roughly comparable to that of modern desktop PCs. It has a particularly stylish case design, but that's all.
"Screaming G5" at, say, $3000, contract programming at, say, $100/h. So, that means you'd have to code something in at most 30h in order to make it worth your while even if you were certain to win. However, given that you will be competing against lots of people who invest irrationally much time, your chances of winning are negligible. Sorry, it's just not worth it.
A shared dorm room is for sleeping, nothing else. Have your roommate pick up his laptop and go somewhere else. Dorms have common areas and universities have computer rooms for that purpose.
There are technical solutions, but they are expensive and miss the point.
Nonsense. Active noise cancelation may generate some noise of its own in the amplifiers, but that's a side-effect unrelated to how it is intended to work.
Furthermore, many people find something like white noise soothing and don't get a headache from it at all. If any kind of sound made us ill, we wouldn't have survived as a species. It's only some man-made sounds that suggest danger that are a problem. Key clicks fall into that category.
The real question, however, is will the .NET framework on Linux be good enough so that people will actually want to use it?
.NET framework that is being implemented as part of Mono is not the preferred way of writing GUI applications, it's a compatibility library.
No, that's not the real question. The
The preferred way of writing GUI apps on Linux in C# is using Gtk# and Gnome. And we already know that that is good enough for people to want to use it.
It's a more established framework and a lot more cross-platform.
Well, first of all, the only full implementations of Java are proprietary. If you use any of the open ones, you miss out on huge chunks of functionality (e.g., there is no open source Swing implementation). Furthermore, Sun's patents and license agreements for Java seem to preclude full open source implementations.
Secondly, I don't want cross-platform support. Sun is making too many compromises in order to force cross platform. It really doesn't matter to me whether my Java application runs well on Windows if it doesn't run well on Linux. C# makes it easy to use platform specific libraries, and that's exactly what I want.
But he doesn't think it's a good thing because then everyone - even on Linux, even on embedded devices - will use .NET and whenever Microsoft feels like it (i.e. when Mono/dotGNU really have a market share) they can enfore their patents and - whooops, Mono/dotGnu have vanished.
.NET. If they chose to exercise that and if it were valid (a big if), then Mono would have to drop .NET compatibility. The effect of that would be minor since most Mono software doesn't use .NET.
.NET patent, will likely have no problems sticking if Sun decides to exercise them. Note also that there is no complete open source implementation of Java.
.NET patent just went away. But between an open source platform (Mono) that is largely legally unencumbered except for a Windows-compatibility library that I don't use (.NET), and a proprietary platform (Java) whose core functionality is covered by Sun patents, Mono seems like the safer alternative. Not perfect, but nothing in this world ever is.
Microsoft has a patent on
Note that, in comparison, the situation for Java is far worse: Sun has dozens of Java-related patents, real patents that, unlike the Microsoft
Yes, it would be better if the
C# is a decent language, and unlike Java, it has an open standard. Why not implement it? That's the way we got C and C++: the GNU project decided to implement an existing standard.
.NET platform, but you don't have to use .NET in order to use Mono. In fact, you probably shouldn't: Gtk# and other Mono-specific libraries are far nicer than the .NET stuff. .NET compatibility is only there as an additional offering for those who need it and want to migrate off of Microsoft's implementation.
It sounds to me like you are confusing the language and the platform. Yes, in addition to implementing C#, Mono is also copying the
In fact, one of the nice things about C# compared with Java is that the C# guys are not religiously cross-platform. You are, in fact, encouraged to use C# the way you might use C and C++: to call the best libraries your platform has to offer. Think of C# just as a better C++; (thankfully) it isn't trying to do what Java is trying to do.
Windows.Forms is part of Microsoft's .NET Framework, and GTK# is Mono's extension to the .NET Framework to allow more portable .NET graphics.
.NET framework. Gtk# is a completely different library and toolkit from .NET. Gtk# is a C# language binding of the Gtk+ library. You don't need to know .NET in order to use Gtk#.
.NET just the same as Mono is.
.NET compatibility. But if that subproject were dropped from Mono, you'd still be left with a vibrant, useful project. It is therefore wrong to talk of Mono as "extending .NET" as if .NET was the foundation of everything Mono does.
Gtk# is not an extension to the
then you'd be extending
Mono is a project that comprises many subprojects. One of those subprojects is
Mono feeds off of the various Linux GUI libararies in order to implement the windowing requirements for .NET.
.NET as a Framework.
.NET is not necessary for making Mono a great programming environment, since Mono has its own set of APIs, APIs that, incidentally, are very easy to use for Gnome and Linux programmers because they are the standard APIs they are alsoread using.
.NET compatibility altogether: it's superfluous and a waste of time. ECMA C# with standard Linux libraries is a better choice and it's already here.
Most GUI apps in Mono are written using Gtk#, through non-.NET APIs.
Mono offers no improvements to
You just have no idea what you are talking about. Mono offers most of Gnome and Gtk+ directly to C# programmers, as well as many other open source libraries that people already know from C and C++ programming.
They are also nowhere near completion of implementing the entire Framework.
And they don't have to be because completing its implementation of
In fact, I wish Mono would just drop
No, it isn't.
So how is it not a knock off? Because it runs on Linux?
Mono is a huge project that encompasses several distinct parts:
- A C# compiler and CLR runtime.
- A large set of open source APIs and libraries, like Gtk#.
- A compatible implementation of the
.NET APIs.
Item 1 is the implementation of a language standard; if it is a "knockoff", then so are GNU C and C++.Item 2 is its own thing, something nobody else has for C#.
Items 1 and 2 are the most important ones for the Mono project.
Item 3 is indeed a re-implementation of a closed source, non-standard API. If you want to call that portion of Mono a "knock-off", then so be it. Keep in mind, however, that most of Microsoft's products are knock-offs as well, as are a lot of other open source projects, so I don't really see what's wrong with being a "knock off", in particular when a project like Mono also has a complete and separate set of APIs.
Mono is simply
No, that is completely and absolutely false.
On the other side of the coin, I can't keep a nanny or cleaning lady twelve hours a day for a week without any extra compensation under threat of termination.
Of course, you can. She would probably just quit her job rather than put up with it. And you have the same choice with your employer: either quit or put up with it.
Object-oriented programming allowed developers to create industrial software that is far more complex than what functional programming allowed.
She means "procedural programming". It's pretty amazing that a "senior IT architect" who makes pronouncements on the future of programming doesn't know the difference between "functional programming" and "procedural programming".
Q: So, your basic thesis is that programming constructs should be more intuitive to developers, and more closely simulate and resemble the real world. That would enable developers to write software with fewer bugs, right? A: Exactly.
What are computers trying to do in the real world? They are trying to solve problems, not simulate problems. The solution to a problem is completely different from its simulation. Yes, the simulation is simpler to implement, but it doesn't solve the problem.
Smalltalk (incidentally, a much better designed language than Java) had the same underlying idea, and it didn't catch on because programming really doesn't work that way. Smalltalk turned out to be a decent programming language but no silver bullet. Unlike Java, Smalltalk was extensible enough that whatever abstractions it was missing in the base language could be added by users.
But expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions -- like processes and conditions -- is only half of the arsenal in the war on complexity.
I see: adding dozens of complex, additional abstractions that can all interact in unpredictable ways is supposed to make programming simpler. PL/I and Ada, here we come.
Enormous productivity gains remain to be uncovered and difficult problems are yet to be solved.
Yes, but evidently not by Sun, since Sun clearly has no idea what they are doing.
From the description, it sounds like if you have multiple pages with different signatures, you get back the OR of their bits. That means you have to ensure that the pages are scanned one-by-one, and at that point, you might as well use an optical barcode anyway.
Examples of this include the company forcing employees to put in extra (unpaid) hours, with the implicit/explicit threat of loosing the job if they don't, to actual personal harassment in the work place by management staff
You should look at your employment contract. There are some employment contracts under which you never get paid overtime, and there are others in which you are. In either case, the employer can fire you if he isn't satisfied with your performance. Maybe the fact that your employer tells you to work overtime is a last opportunity he is giving you for making up work you should have been getting done during working hours if you had been reasonably effective (and not been posting on Slashdot).
My experience is that even in cases where the employee is completely right, it is impossible for her to win the case, given current employment law."
Of course, and why not? There is a small set of things your employer cannot fire you (e.g., your race). Anything else is fair game. After all, you yourself wouldn't want to be forced to keep employing a nanny or cleaning lady if you don't like the way she is performing. Why should your employer be forced to do the equivalent, then?
C# is a nice language, it's free, open, and standardized, and it's good that there are many implementations of it. All those other points don't matter.
.NET remains proprietary, all the better as far as I'm concerned: I like the language, not MS libraries.
What MS does or doesn't do with C# is their business. And if
Ah, the Macintosh and Qt zealots never fail to disappoint: criticize their obsession and they mod you down.
An old adage that governments would be well-served to heed is: You get what you pay for.
Quite right.
When you rely on free or low-cost products, you often get the shaft, and that, in my opinion, is exactly what governments are on track to get.'
Well, then open source shouldn't be a concern. Open source software isn't "free" as in "no cost". Quite to the contrary: open source software may well require you to pay considerably more for skilled developers and skilled system managers to adapt and deploy it. And in return for doing so, you get better quality software and you lower your overall operating costs. The fact that open source also happens to save you licensing fees is icing on the cake.
That is in sharp contrast to a lot of commercial software that promises to be so trivial that even an untrained monkey can use it. Of course, it doesn't actually deliver on those promises--many problems are just intrinsically hard and no matter how many dialog boxes and help files you add, people still won't be able to use it--but it gives the appearance of doing so, and that is arguably far worse.
In different words, the commercial software vendors are in the tradition of snake oil salesmen and miracle healers, who charge a huge amount of money for their miracle cures and try to keep charging you. Open source developers, in contrast, are more often in the category of skilled medical professionals: you hire them, you pay them a good salary, they solve your problem, and then they go on to the next patient.
Technically, ePalm sounds like it might be a good thing. SmartEiffel, which it is based on, can generate quite compact native code even from large, object-oriented libraries because it performs global optimizations; that makes it a better choice than VM-based systems like Java or .NET. Furthermore, PalmOS doesn't isolate programs very well from one another, so a language like Eiffel, with built-in garbage collection and error checking, has a real advantage over C.
Still, SuperWaba probably fills that niche well enough and Palm handhelds are getting powerful enough so that the advantages of ePalm won't be big enough to let it catch on.
Except that GPL Qt is available for the Mac. So, it is functionally no different than programming something in pure Qt for Linux, at least with regards to promoting their 'commercial' and 'proprietary' product.
Yes, you are quite right: it is very similar.
Unless you are also against all Qt programming in Linux? Or are you fully against free software on the Mac?
I don't know what you mean by "being against it". I think Troll Tech had a mediocre toolkit that only succeeded because of their licensing gimmicks and they have taken unfair advantage of gullible open source developers in order to succeed. When you develop a good application for Qt or Macintosh, you are giving those two companies a huge, free gift. Why would you want to do that when you could instead create software on/for open source platforms that you yourself have full control over?
So, I think it's stupid for you to develop open source software in Qt or for Macintosh. But you have a right to be stupid, so in that sense, I'm not "against it", I'm just pointing out your stupidity.
Studies like this one may lead to smarter urban-growth strategies in the future.
I really doubt it. There are much bigger, more immediate problems with our "urban-growth strategies" than that (pollution, traffic, etc.), problems whose solution would result in enormous and immediate benefits to every resident. Since we don't manage to solve those, something as abstract and without direct impact as the use of fertile land to build cities on will lead to anything.
Clearly your utility is equivalent to your economic gain.
When developing software whose purpose is to promote other companies' commercial platforms, you bet it is. That kind of thing, I expect to get paid for.
For many other kinds of software development, I develop and share it freely. That has many non-monetary benefits. But those don't apply in this case.
GTK may be more efficient for *NIX/X11 development, but it doesn't touch Qt in the cross platform arena.
No, but Gtk+ runs natively when you run it on the Mac because Apple now has a pretty good official X11 server for OS X, and they keep improving the integration of it into the desktop.
Sorry, but with this logic, there would never be any Linux or GNU software.
No: Linux and GNU software is open source software for an open source platform. Even when GNU software was originally developed, the fact that it ran on SunOS was viewed as a temporary compromise, with the long term goal of replacing SunOS with something open source.
The Qt/Mac competition promotes the creation of software for a proprietary toolkit on a proprietary platform and has no intention of replacing either of those proprietary tools with anything free.
Now getting something as frivolous as Apple G5 is nice, since most rational people realise that they don't really need a G5 and so won't buy it.
I don't see anything "frivolous" about a G5--its performance is roughly comparable to that of modern desktop PCs. It has a particularly stylish case design, but that's all.
"Screaming G5" at, say, $3000, contract programming at, say, $100/h. So, that means you'd have to code something in at most 30h in order to make it worth your while even if you were certain to win. However, given that you will be competing against lots of people who invest irrationally much time, your chances of winning are negligible. Sorry, it's just not worth it.
Come on, this is elementary stuff. Sound consists of both compression and rarefactions of the air; the average pressure remains unchanged.
A shared dorm room is for sleeping, nothing else. Have your roommate pick up his laptop and go somewhere else. Dorms have common areas and universities have computer rooms for that purpose.
There are technical solutions, but they are expensive and miss the point.
Nonsense. Active noise cancelation may generate some noise of its own in the amplifiers, but that's a side-effect unrelated to how it is intended to work.
Furthermore, many people find something like white noise soothing and don't get a headache from it at all. If any kind of sound made us ill, we wouldn't have survived as a species. It's only some man-made sounds that suggest danger that are a problem. Key clicks fall into that category.
Active noise cancellation works for hums and drones (steady low frequency noise), not clicks. So, it's useless for this purpose.