Particular to this project 'hack' in CSS generally refers to literally adding hacks in to force something to work, it's not a synonym for tinkering. If the whole project is chock-full of `! important` statements and specific `-moz/-webkit/-ie` prefixes to selectively cover specific bugs, then maybe it would be well-named (if horrific). I get why it's called 'hack', but given that in the context of CSS, 'hack' is almost always perjorative – referring to awful, unclean things you do to bend CSS styling to your will – it's not a very good name.
It's a name which is confusing and difficult to search - almost as bad as calling the (Haskell) build tool 'stack', but with added negative connotations.
That's pretty much what CSS frameworks are: a set of pre-built items you can use to build your site, so you don't have to do it all yourself. Don't ask me why, ask whoever wrote the first CSS framework.
Well, yeah. But I wouldn't say that frameworks are INHERENTLY antithetical to the sprit of hacking. A framwork approximating a library, like Mithril, provides a useful set of abstractions and code for building your project. What IS antithetical to hacker sprit is frameworks that like rails that believe that there is one way to do it, only one way to do it. And if you would like to write or organize your code another way, shut up, you're wrong. Not that that's necessarily bad, but it's directly counter to the hacker spirit.
(I don't know anything about Mithril, so I can't comment. Everything I've ever used that's a "framework" rather than a "library" tends to be pretty restrictive, and I feel like many frameworks do all the fun stuff for you, leaving you with just the boring stuff to do).
Mithril defines a vdom, routing, a $.ajax style XHR request, a few handy wrapper functions, an mvc-style structure for your apps, and a rendering loop that knows about ajax, and can be integrated with external libraries, so it only rerenders when necessary, and not while the application's state is inconsistant. However, the VDOM implementation, and kinda-sorta-not-really the MVC structure is all that's required. Yes, you can even write your own render loop if you want. Although why you'd want to do that is beyond me.
Some of this is nice, but I don't get why you would want your output to look like markdown _before processing_. Why can't the headings be headings, without the "##"s etc.
Because to some of us, including me, actually, that kind of markdown markup is quite pleasing to the eye, as well as providing addtional visual queues. You can never have too many of those, provided they are well designed.
Because npm is a package manager that most devs already need present for their front-end build step (to install their deps for gulp/grunt/browserify etc) , and bower is an 'extra' thing that addressed a need that no longer exists.
I think the trend of front-end projects not providing a compiled `dist` folder with the assets for web inclusion to be a bad idea. This requires me to NPM install this "front-end code" (no Bower) and then add this Gulp compilation to my build. What happened to adding a `dist/hack.min.css`? Why no Bower?
Yea, but how does that help me in my dev projects? The nice thing about Bower/NPM is that you can pull repos at specific versions or pull in new versions of a project. Adding a line to my build script to include a file at (say) `./vendor/hackcss/dist/hack.min.css` is a lot easier than having to run his Gulp compilation script. CURLing or including this public link isn't really an option :/
Then I didn't understand the complaint, as this does include a dist/ folder in the npm package (which is also what npmcdn uses), so you'd just npm install it as normal :)
Yes, when you publish an NPM package it grabs anything not ignored by .npmignore or .gitignore, which can include css, a dist folder, etc., quite useful!
Would that not pollute the git history of the project with "junk" diffs of the compiled min.css file? I can see people not wanting to do that on principle.
But yeah, I would really like a way for the builds to be available in the way you describe without any git history issues.
Please stop calling your project '<x> for hackers.' It's annoying, regardless of whether your project shows any of the concepts or ideals associated with hackers (either kind). Which most of these projects don't.
Besides, it's a trend that's really easy to satirize.
Here's a fun game: describe an "os for hackers." See how long it takes for the person you are talking to to realize you're describing ITS. You win if the person fails to realize this, and actually says they would want to use said system today. For bonus points, cart in a PDP-10: their new 'working environment'. :-D
ITS was good. For something a little more recognizable (and probably more achievable on current hardware), MS-DOS was actually pretty good from the hacker's point of view (and FreeDOS continues that legacy).
I say this because DOS was an OS that didn't get in your way. No, it didn't afford you any conveniences, really. It gave you a (shitty) file system, command line, program loader, a handful of utilities, and practically nothing else. Not exactly user-friendly. However, it also gave you completely unfettered access to the underlying hardware. The Intel reference manuals and a good assembler, and you could do literally anything. Since it was single-tasking, once your program was loaded, it had complete control and owned the entire physical address space. There was nothing to prevent you from calling into the BIOS, or doing I/O willy-nilly to ports, peeking/poking randomly into memory, etc. There's a reason why several OS's were bootstrapped on top of DOS, including Windows: it gave you just enough conveniences that you didn't have to start from total scratch, but it did so little that it never got in your way or otherwise prevented you from doing whatever you wanted.
I occasionally fire up FreeDOS on an old P2 or in a VM and just tinker. If I were to produce a real product, I'd obviously be better off writing something for Linux or BSD kernelspace, but for exploring the way hardware gets programmed on its lowest level, DOS is pretty indispensable. I'd liken the difference between low-level programming on DOS and the same on Linux/BSD to the difference between using an interactive interpreter and a batch compiler. It really can enable low-level experimentation in much the same way.
Hey, I have an UP account. I don't deny that ITS was good. But it's not a system that you can use for Real Work today. It is literally worse than some implementations of DOS in some respects. Although not all, obviously.
I should probably play around a bit with DOS at some point. Know any good references?
Oh, of course I wouldn't recommend ITS for real work today. I wouldn't recommend DOS for real work today, either. But hacking isn't always "real work", per se: sometimes it's just tinkering, experimenting, learning, or pushing the system to its limits, etc. Hacking is an opportunity to be knowledgeable, intelligent, creative, and productive at the same time. You could say that, when it comes to hacking, Unix-like systems are like coloring books, in that they're already partially created for you, and whatever you come up with has to fit within that pre-defined framework. ITS and DOS, on the other hand, are more like a blank sheet of graph paper ;)
You'll want a good assembler, too, even if you wind up writing most of your code in a high-level language. GNU as ("gas") is okay, but I prefer the Flat Assembler ("fasm"), the Netwide Assembler ("nasm"), or Yasm (... "yasm"). I think you can still get MASM from Microsoft, but I don't know if recent versions still support DOS targets. You can probably also find older versions of MASM and TASM online somewhere.
Sometimes I'll do my coding directly in DOS, if only for the nostalgia. You might have better luck using more modern tools for development and cross-compiling or cross-assembling. If you want some higher-level DOS tools, here's a (partial) rundown of what I've used:
For real-mode (16-bit) programming, it's hard to beat Borland's old "Turbo" line of tools. Borland used to have a "museum" site where you could download old versions of Turbo C, Turbo C++, and Turbo Pascal for DOS for free. I don't know if the museum is still around, but you should be able to find copies of the tools. There's also Pacific C which is freely available and includes a somewhat Turbo C++-style IDE (but with a different color scheme), and OpenWatcom, which is open-source nowadays and comes with a decent vi clone. I remember a few FORTHs for DOS, too; PC Forth was pretty nice. Might be able to find that somewhere on the 'net still.
For protected-mode (32-bit) programming, I'd recommend DJGPP (Delorie's GNU tools for DOS, including GCC, gmake, and gas), FreePascal, and/or FreeBasic. If I recall correctly, they all include a suitable DPMI server (a.k.a. DOS extender) to provide DOS syscalls in protected mode. OpenWatcom can target protected mode, too; its extender DOS4GW has not been open-sourced with the rest of the system (at least, it wasn't a few years ago). Regardless, DOS4GW is a solid extender and was very popular once upon a time.
Some even-higher-level languages run fine in DOS, too. Lua comes to mind, and I remember messing with Logo, Tcl, Common Lisp, and Scheme on DOS before (XLISP comes to mind). I think DJGPP might have a Perl interpreter for DOS, but since I've never liked Perl, my memory may be hazy on that one ;)
FreeDOS also has a package repository with loads of software including development tools.
I'm not aware of any tools for doing long-mode (64-bit) programming on DOS. I'd assume you'd at the very least either need a DPMI-type thing for long-mode (LPMI?), ...
Thanks. I do agree that hacking isn't always real work. Like I said, I have an account on one of the last public-access ITS systems in the world.
And I have to say, coloring books are pretty fun. Which is to say, I really like UNIX. The (almost) everything is a file model makes dealing with external devices remarkably simple, compared to other systems. And the predisposal towards textuality makes system configuration fairly simple, with little need for special tools. Pipes and sockets make program composition simple, so you can build several small programs instead of one big one, or compose together smaller programs instead of writing a new one. And shell, while not perfect, makes simple automation easy.
It's not a perfect system, but it usually works, and it's pretty damn elegant for a system built as what was effectively a weekend hack in the '70s.
Oh, and do you know if any assemblers other than GAS support AT&T syntax? I think it's much nicer.
> And I have to say, coloring books are pretty fun. Which is to say, I really like UNIX. The (almost) everything is a file model makes dealing with external devices remarkably simple, compared to other systems. And the predisposal towards textuality makes system configuration fairly simple, with little need for special tools. Pipes and sockets make program composition simple, so you can build several small programs instead of one big one, or compose together smaller programs instead of writing a new one. And shell, while not perfect, makes simple automation easy.
I agree completely. But I still think it's fun to let loose on the hardware sometimes ;)
> Oh, and do you know if any assemblers other than GAS support AT&T syntax? I think it's much nicer.
Hello & Thank you : The article is really awesome. Sometimes really urgent to find or hire a hacker. We need to safe and protect our data and information from our cyber crime. For ethical hackers may please visit - http://hackerslist.co/ here are a best team of professional ethical hackers & feel free to contact here http://hackerslist.co/
61 comments
[ 2.7 ms ] story [ 96.2 ms ] threadShould Apple have not called their notebook MacBook Air because of Adobe AIR?
It's in field that's close enough. What will you say after, "I wrote my website in Hack and Hack"?
Not optimal, but it works.
Or am I missing something?
Well... move along please, nothing to see here.
But I agree with the sentiment. Frameworks seem pretty much antithetical to the spirit of hacking.
(I don't know anything about Mithril, so I can't comment. Everything I've ever used that's a "framework" rather than a "library" tends to be pretty restrictive, and I feel like many frameworks do all the fun stuff for you, leaving you with just the boring stuff to do).
http://m.imgur.com/3uzsU8p
I never used one and everyday there is another one on HN, confusing me with all its features xD
http://npmcdn.com/hack
But yeah, I would really like a way for the builds to be available in the way you describe without any git history issues.
Besides, it's a trend that's really easy to satirize.
Here's a fun game: describe an "os for hackers." See how long it takes for the person you are talking to to realize you're describing ITS. You win if the person fails to realize this, and actually says they would want to use said system today. For bonus points, cart in a PDP-10: their new 'working environment'. :-D
I say this because DOS was an OS that didn't get in your way. No, it didn't afford you any conveniences, really. It gave you a (shitty) file system, command line, program loader, a handful of utilities, and practically nothing else. Not exactly user-friendly. However, it also gave you completely unfettered access to the underlying hardware. The Intel reference manuals and a good assembler, and you could do literally anything. Since it was single-tasking, once your program was loaded, it had complete control and owned the entire physical address space. There was nothing to prevent you from calling into the BIOS, or doing I/O willy-nilly to ports, peeking/poking randomly into memory, etc. There's a reason why several OS's were bootstrapped on top of DOS, including Windows: it gave you just enough conveniences that you didn't have to start from total scratch, but it did so little that it never got in your way or otherwise prevented you from doing whatever you wanted.
I occasionally fire up FreeDOS on an old P2 or in a VM and just tinker. If I were to produce a real product, I'd obviously be better off writing something for Linux or BSD kernelspace, but for exploring the way hardware gets programmed on its lowest level, DOS is pretty indispensable. I'd liken the difference between low-level programming on DOS and the same on Linux/BSD to the difference between using an interactive interpreter and a batch compiler. It really can enable low-level experimentation in much the same way.
Anyway, ITS was the bee's knees.
I should probably play around a bit with DOS at some point. Know any good references?
Here are some resources for DOS:
Ralf Brown's Interrupt List is very handy when doing low-level DOS programming: http://www.cs.cmu.edu/~ralf/files.html
The Intel architecture reference manuals, too: http://www.intel.com/content/www/us/en/processors/architectu...
Delorie Software maintains a linklist for assorted documentation: http://www.delorie.com/djgpp/doc/
You'll want a good assembler, too, even if you wind up writing most of your code in a high-level language. GNU as ("gas") is okay, but I prefer the Flat Assembler ("fasm"), the Netwide Assembler ("nasm"), or Yasm (... "yasm"). I think you can still get MASM from Microsoft, but I don't know if recent versions still support DOS targets. You can probably also find older versions of MASM and TASM online somewhere.
Sometimes I'll do my coding directly in DOS, if only for the nostalgia. You might have better luck using more modern tools for development and cross-compiling or cross-assembling. If you want some higher-level DOS tools, here's a (partial) rundown of what I've used:
For real-mode (16-bit) programming, it's hard to beat Borland's old "Turbo" line of tools. Borland used to have a "museum" site where you could download old versions of Turbo C, Turbo C++, and Turbo Pascal for DOS for free. I don't know if the museum is still around, but you should be able to find copies of the tools. There's also Pacific C which is freely available and includes a somewhat Turbo C++-style IDE (but with a different color scheme), and OpenWatcom, which is open-source nowadays and comes with a decent vi clone. I remember a few FORTHs for DOS, too; PC Forth was pretty nice. Might be able to find that somewhere on the 'net still.
For protected-mode (32-bit) programming, I'd recommend DJGPP (Delorie's GNU tools for DOS, including GCC, gmake, and gas), FreePascal, and/or FreeBasic. If I recall correctly, they all include a suitable DPMI server (a.k.a. DOS extender) to provide DOS syscalls in protected mode. OpenWatcom can target protected mode, too; its extender DOS4GW has not been open-sourced with the rest of the system (at least, it wasn't a few years ago). Regardless, DOS4GW is a solid extender and was very popular once upon a time.
Some even-higher-level languages run fine in DOS, too. Lua comes to mind, and I remember messing with Logo, Tcl, Common Lisp, and Scheme on DOS before (XLISP comes to mind). I think DJGPP might have a Perl interpreter for DOS, but since I've never liked Perl, my memory may be hazy on that one ;)
FreeDOS also has a package repository with loads of software including development tools.
I'm not aware of any tools for doing long-mode (64-bit) programming on DOS. I'd assume you'd at the very least either need a DPMI-type thing for long-mode (LPMI?), ...
And I have to say, coloring books are pretty fun. Which is to say, I really like UNIX. The (almost) everything is a file model makes dealing with external devices remarkably simple, compared to other systems. And the predisposal towards textuality makes system configuration fairly simple, with little need for special tools. Pipes and sockets make program composition simple, so you can build several small programs instead of one big one, or compose together smaller programs instead of writing a new one. And shell, while not perfect, makes simple automation easy.
It's not a perfect system, but it usually works, and it's pretty damn elegant for a system built as what was effectively a weekend hack in the '70s.
Oh, and do you know if any assemblers other than GAS support AT&T syntax? I think it's much nicer.
I agree completely. But I still think it's fun to let loose on the hardware sometimes ;)
> Oh, and do you know if any assemblers other than GAS support AT&T syntax? I think it's much nicer.
I think YASM supports AT&T syntax.
And thanks.
It's kind of sad that it isn't.