Domain: pluralsight.com
Stories and comments across the archive that link to pluralsight.com.
Comments · 19
-
Re:SQL Server, thanks
I'll leave this here. It's an interesting series of videos that explain features of Postgres that SQL Server doesn't have. It also explains why many developers are moving from SQL Server to Postgres.
Pluralsight Tekpub Postgres videos -
Re:Adapt
http://www.pluralsight.com/community/blogs/mike/archive/2004/05/25/415.aspx
Q) Why did the multithreaded chicken cross the road?
A) to To other side. get theQ) Why did the multithreaded chicken cross the road?
A) other to side. To the get -
Re:What about C#
-
Re:Where have I heard this before?
The split program is a bit safer than before.
-THe user can only do things the service in designed to do.
-Becuase less code runs in administrator mode (is it? ) it is easier to edit.
-less odds to have a luring attack -
Re:What's new?
i hold notepad in the highest regard as a text editor
ACK
Notepad is terrible!!! I mean:- No syntax hilight
- No completion
- Size limitations
- No line/column numbers
- No code folding
- No incremental search
- And the worst: it has bugs!! Even simple as it is!!
Use emacs, gedit, kate, or even notepad+ for a while and you will never use notepad again!
-
Re:Because it makes things work.
I can list tons. The reason people don't give out lists of programs is because there are so many that it just seems obvious. Kind of like saying "Fire can burn you" and then listing a bunch of newpaper articles about people getting injured from burns. I've run my Windows box as a limited user for a long time now, and if administering Windows wasn't what I do for a living, then I probably would be completely lost trying to get things to work.
* Crimson Editor (a code editor - saves config to program directory)
* WinTV2000 (for my Hauppauge TV Card - saves config to program directory)
* WintV Scheduler (for my Hauppauge TV Card - saves config to program directory)
* DVD Movie Factory 3 (Came with Hauppauge TV Card - loads a device driver when run)
* Plextools Professional (App for my Plextor DVD Burner - needs direct access to hardware + saves config files in program directory and/or HKEY_LOCAL_MACHINE\Software)
* Trillian - writes config files to program directory
* Win AMP - writes config files to program directory
Now these are just apps I either use right now, or have used recently that either break completely or don't fully work without admin rights. Almost all of the programs can be fixed with simple file permission changes (simple if you use XP Pro. With XP Home it's not so simple), but a couple are not so simple. Nero Burn rights has to be installed to make plextools work, and the WinTV apps were fixed by giving users rights to a reg key in HKLM\SOFTWARE. What's perplexing about the WinTV apps is when monitoring it, they never actually wrote anything to the key I had to give access to. It just checked to see if they could write to it and died if it couldn't. As for DVD Movie factory, I haven't been able to get it to work as a non-admin. It loads some sort of driver on startup and even when you give users the right to load and unload device drivers it doesn't work. For it, I use the hack linked to in my sig.
If you only use MS products, then running as a non-admin isn't that hard, because MS if pretty good at writing their apps to work as non-admin but when you delve into the world of third party software in Windows, apps that break are very common.
The most frustrating part is that it's not that complicated to write a Windows app that works properly as non-admin. In 99% of cases, you can get by following two rules - 1) Don't write to the program directory after install and 2) Don't write to HKLM\Software\ after install. That's it.
Here are some more links to software that break as admin....
http://www.threatcode.com/admin_rights.htm
http://www.pluralsight.com/wiki/default.aspx/Keith .HallOfShame
It seems to be getting better now. Five years ago, programs that work as a limited users in WIndows were almost non-existant. Now it seems the majority of new products that come out work jsut fine - but there are still offenders out there that ruin it for everyone. -
Re:Because it makes things work.
Ask and ye shall receive: Keith Brown's Hall of Shame.
-
Re:Summary
So i wouldn't be surprised at all to see MS drop managed C++ entirely.
Actually, MS is pushing C++/CLI for standardization. The .Net 2.0 Managed C++ is much less ugly than in .Net 1.x.
The nice thing about .NET though is that you aren't stuck to any particular language though...
Everyone touts this, and I agree that it's a seductive idea. However, I think few people consider the likely long-term ramifications, particularly in large applications built, augmented and maintained over long periods of time. Imagine some large organization having an internal CLR application which has accreted multiple modules in several .Net (or Mono) languages. Now imagine that Mr. VB.Net needs to track and correct a flaw in a module written by Mr. Perl.Net long after Mr. Perl.Net has left the company. Some will say that the modules written by Mr. Perl.Net would have been appropriately designed & documented so that any other CLR developer can understand & modify them regardless of programming language - but that doesn't happen on the planet most of us live on, especially with internal applications.
So in short, they're forcing you to .NET, but not off any particular language.
Agreed. MS gains the most as more developers move to a platform it "controls" - how much control is debatable, but I think no one is foolish enough to believe that MS's .Net push is in any way altruistic. However, the native Win32 C++ developers will be the hardest to convert, and that's why MS is investing effort in C++/CLI to entice them. Few native C++ programmers have any love for MFC, but also few seem willing to leave native Win32 for .Net drag-and-drop GUI capabilities. And for desktop/server applications, experienced C++ devs already know what native APIs to use for whatever they're working on - there's a perception that .Net has little to offer them when building these apps. That's a big hurdle for MS if they intend (regardless of their current public stance) to derive a crushing long-term strategic advantage from mass adoption of .Net.
T -
Free Online
The book was developed online via a Wiki, available here for free. This is a great book that every windows and
.NET developer should be aware of. -
Hate to do this but
this book can be read online for FREE as in beer or something. If you want it in one document you may have to get your "copy and paste" on, or if you are in hacker fever you could screen scrape it. Anyway http://pluralsight.com/wiki/default.aspx/Keith.Gu
i deBook.HomePage yep all there for your Windows security mokery.
Remember this is to build secure software on Windows, something that should not be frowned upon even if those who write Windows don't listen to this advice. So when your next Window app breaks and your customer is irate, you can say "uh uh that's MS Slammer 5002, that's a bug with Windows not my code buddy!! I know my shit and that's why you're paying me too much to do this, now stop bugging me already, don't you accountants do anything but make cups of coffee all day!!!!"
Read the Book. -
Don Box asked before. I suggested LOGO
Don Box had a simular journal post about which language was best to teach his kids to program. I felt that LOGO was the best choice.
When I was younger, the ability to program the robotic turtle really empowered me! The fancy shapes and colors produce amazed me, and it made me feel like I was accomplishing something. It isn't a coincidence that one of the first things I programmed in Integer BASIC (my second language) was a clone of LOGO for the IIgs (also, we couldn't afford a copy).
I still feel that way. In fact, to learn to program you really should start with simple text-only (like command line) or path-only (like turtle maps) interface stuff. Anything else requires the ability to think in terms of metaphors that are hard for newbies to grasp. It also helps new programmers learn to program in steps (i.e. design) rather than struggle with the grammar or vocabulary (i.e. one big main function).
-
Longhorn was NEVER supposed to be built on .NET
Dear Misinformed Idiots:
Longhorn was never supposed to be re-written or even based on .NET. That was never the plan at all. Longhorn will expose more existing functionality through managed [.NET] interfaces plus NEW functionality like Indigo http://pluralsight.com/blogs/dbox/archive/2005/02/ 06/5596.aspx and parts of Avalon will be written in .NET. Much of Longhorn is NT/Windows 2000/XP/2003 c/C++ codebase. There will lots of new functionality written in .NET. But the vast majority of the Longhorn codebase will remain in C/C++. And that was always the case. -
Why?
People do this all the time, in message boards and on blogs, usually with a standard disclaimer that opinions expressed are not of their employer.
There are so many examples of this... Look at how many Microsoft employees have blogs like Scoble or Don Box, or Oracle's Tom Kyte, or IBM's Kyle Brown, or BEA 's David Orchard (I work for BEA as well) , or Google's Bosworth.. Do you really think these people are vetted by PR? How many employees post to newsgroups or public tech support forums... I see people get into public flamewars too.
On the other hand, there is a problem here with what constitutes a company's "voice". Bosworth, for example, gets into controversy for people confusing his opinions with Google's (or BEA's , previously).
Frankly, I tend to side with the cluetrain. As long as you don't claim to hold the "official" position, and don't talk about internal confidential information, it's beneficial to the company, its investors, customers, and prospects for employees to engage in open and honest dialogue with others.
I guess it depends on how paranoid you are about your company firing you for speaking your mind. Generally I don't get too concerned about it, if they did such a thing, I wouldn't want to work for them anyway. -
Who is the target audience?I've read through much of the witty banter on
/. regarding Indigo, Longhorn, Avalon, and WinFS.
I can only assume that the people that understand how XML, Web Services, Service Oriented Architecture, Enterprise Application Integration effect large corporations have remained silent.
The people that have replied have stated clearly that they don't know what Web Services are, have never worked with XML, and don't understand how EAI has changed the way businesses do things.
Indigo is an extraordinary technology that will very likely be copied by IBM for Java (IBM and Microsoft both partnered on all of the WS-* standards) and will usher in a whole new era of interoperability for the business world.
If you're even the slightest bit curious about what this is all about I suggest the following reading material:
http://community.java.net/java-ws-xml/
http://msdn.microsoft.com/Longhorn/understanding/
p illars/Indigo/default.aspxhttp://pluralsight.com/blogs/tewald/default.aspx I'm sure there is a lot more.
-
Re:The Tandy COCO Guy!
If you're gonna go with BASIC, might I suggest VBScript or JavaScript or ActionScript (Flash). Of course, others might suggest Java or SVG. Or, Lisp, SmallTalk, ML, or Ruby. JavaScript and VBScript at least you can develop without having to download any compilers. If you were leaning towards Java, Python is another good choice in that direction.
-
Why C++ on .NET is right for securityI think he's highlighting that security is a genuine concern (which is good), but he seems to be misinformed about how C++ is actually supported on
.NET. If the situation were what the article seems to indicate, I'd be concerned too.Fortunately, it's not. Maybe I can provide some more context about my design so that he can see how this is a choice that makes the world more, not less, secure.
You can and should write perfectly verifiable code in C++ targeting
.NET, perfectly safe code where you're not allowed to use those dangerous casts, etc. It's called
and it's encouraged. And writing verifiable C++ code means a lot more than just writing C# code in C++ syntax (though you can do just that if you like) -- you also get to use templates and automatic destructors and other major C++ power features safely and verifiably. /clr:safeFor example, consider one of those other C++ power features: STL. Of course, the plain native STL isn't bounds-checked or verifiable. But we also provide a complete STL/CLR library (previously also called STL.NET) which is fully verifiable. STL/CLR is a library that brings all of C++'s familiar containers, iterators, and algorithms straight to the managed world with full interoperability with the CLI container interfaces. This is what you can do (only) in a language that supports both templates and generics: Have a template, like stdcli::vector, that implements a generic interface, like IList. You can use it as a vector (it is one); code that uses a std::vector today can work seamlessly with a stdcli::vector. You can use it as an IList (it is that, too); C# and VB (and C++) code can happily foreach on it.
And I think I already mentioned this is all completely safe and verifiable.
STL/CLR is an example of how C++ on
.NET really brings together the best of both worlds, with no compromises: C++ code gets its usual full STL style of programming and full template specialization and everything else that makes the Standard C++ language and library so powerful. And you can still take one of those container objects and pass it directly to a C# or VB app that can use it naturally. It's safe.Sure, you can also explicitly disable safe mode and write/call unsafe code too if you want -- in any language. That's not specific to C++; you can do that with C# unsafe and Java JNI. If it's immoral to call into unsafe code when you need to, why does C# have unsafe, and why does Java have JNI?
One thing this discussion does underscore, though, is the design choice difference between the JVM's "one language" and the CLR's "many languages." There's a lot of C++ code out there. Which is better for security -- to ignore that code and tell people to throw it all away because tossing it is good for them, or to give C++ developers an easier migration to take their existing valuable code and make it also be safe and verifiable?
For those interested in some more details, I've written about a number of these issues on my blog.
Cheers,
Herb
-
Re:Have we hit a wall for computational ability?
Right, and this sea change has other interesting consequences too. See also my recent blog at http://pluralsight.com/blogs/hsutter/archive/2004
/ 12/17/3957.aspx about The Concurrency Revolution. It's an overview of an article I just wrote on exactly this topic that will appear in the March issue of Dr. Dobb's Journal. A shorter version will be in the February C/C++ Users Journal. -
now a days, it IS user error
Let me preface this with the statement that the lax security in pre-SP2 IE is shameful. But MS has realized it's faults, and they are quickly securing their products. You can ascribe whatever evil motivation you like to the security push.
While there have been a few viruses in the past that legitimately exploited vulnerabilities (like buffer overflows and such), all of the spyware in the post SP2 world requires (a) user intervention (pressing yes at a prompt) and (b) running as admin.
Make your grandma a limited user, and even if she presses yes at the prompt, the installation will fail and she'll remain spyware free. While you are at it, you can install Mozilla and let her discover the joys of tabbed browsing.
Here are some resources that might help:
http://www.techproblemsolver.com/limited.html
http://www.dotnetdevs.com/articles/RunningAsNonAdm in.aspx
http://blogs.msdn.com/aaron_margosis/
http://www.pluralsight.com/keith/book/html/howto_r unasnonadmin.html
http://support.microsoft.com/default.aspx?scid=kb; en-us;305780 -
SINGLE BEST SOLUTIONStop running your daily desktop account as Administrator. Most, if not all, of the spyware will fail when it attempts to infect your system. It's just general good practice anyway. No one runs KDE/Gnome as root, or log into their OSX machine as root. Neither should we.